| Unix timestamp (seconds) | 1,640,995,200 |
|---|---|
| In milliseconds | 1,640,995,200,000 |
| UTC date & time | Saturday, January 1, 2022, 00:00:00 UTC |
| Day of week (UTC) | Saturday |
| ISO 8601 | 2022-01-01T00:00:00Z |
| RFC 2822 | Sat, 01 Jan 2022 00:00:00 +0000 |
| Your local time | — |
| Day of year | Day 1 of 2022 (365 days) |
| ISO week | 2021-W52 |
| Days since epoch | 18,993 full days exactly |
| Julian Date | JD 2459580.50000 |
| Hexadecimal | 0x61CF9980 |
| Binary (32-bit) | 01100001 11001111 10011001 10000000 |
| Read as milliseconds | Monday, January 19, 1970, 23:49:55 UTC — the classic off-by-1000 mistake |
| 32-bit signed | Fits in a signed 32-bit integer with 506,488,447 seconds (16 years, 18 days) to spare before the 2038 limit. |
| Previous milestone | 1600000000 (Round Timestamp 1.6 Billion) is 474.5 days earlier |
| Next milestone | 1672531200 (Start of 2023) is 365 days later |
What does the timestamp 1640995200 mean?
The Unix timestamp 1,640,995,200 pins down midnight UTC at the start of 2022: the instant the clock struck 00:00:00 UTC on Saturday, January 1, 2022. Year-boundary values like this one are everywhere in analytics and reporting code.
The first second of 2022 in UTC. Storing the start-of-year timestamp is a standard trick for "is this event in 2022?" range checks without parsing date strings.
Why 1640995200 matters
The first second of 2022 in UTC fell on a Saturday, and that detail has a consequence developers trip over: because January 1, 2022 was a Saturday, it does not belong to ISO week 2022-W01 at all. Under ISO 8601 the first week of a year is the one containing the first Thursday, so the first three days of 2022 belong to week 2021-W52, and any report grouped by ISO week will file this timestamp under the previous year. 2022 was a common year of 365 days, or 31,536,000 seconds, so the closing boundary is 1672531200, the start of 2023. The timestamp is 18,993 days after the epoch. It arrived barely three weeks after the Log4Shell vulnerability in Log4j was disclosed on December 9, 2021, which is why so many on-call logs from that holiday season are dense with entries just before and after this value. If you are writing a year-range filter, prefer this integer to a date string: it is time-zone-free, needs no parsing, and sorts correctly whether stored as a number or as fixed-width text.
The exact value, every way you need it
A Unix timestamp is a single integer: the count of seconds elapsed since the Unix epoch (midnight UTC on January 1, 1970), ignoring leap seconds. The value 1,640,995,200 seconds is the same instant as 1,640,995,200,000 milliseconds — the form most programming languages expect, since JavaScript, Java, and many databases store time in milliseconds. Written out in full it is Saturday, January 1, 2022 at 00:00:00 UTC, which is a Saturday. In the two most common machine-readable formats it is 2022-01-01T00:00:00Z (ISO 8601) and Sat, 01 Jan 2022 00:00:00 +0000 (RFC 2822). All of these describe one and the same moment in time; they differ only in notation.
How to convert 1640995200 in code
Turning this timestamp into a human-readable date takes a single expression in most languages. In JavaScript, remember to multiply by 1000 because Date works in milliseconds: new Date(1640995200 * 1000).toUTCString(). Here are the equivalents in three common environments:
// JavaScript const ts = 1640995200; const date = new Date(ts * 1000); // JS uses milliseconds console.log(date.toUTCString()); // Sat, 01 Jan 2022 00:00:00 GMT console.log(date.toISOString()); // 2022-01-01T00:00:00Z
# Python 3 from datetime import datetime, timezone ts = 1640995200 print(datetime.fromtimestamp(ts, tz=timezone.utc)) # 2022-01-01 00:00:00+00:00
# Bash / GNU date date -u -d @1640995200 # Sat, 01 Jan 2022 00:00:00 UTC # macOS / BSD date date -u -r 1640995200
If you would rather not write code at all, the Epoch Converter is pre-loaded with 1640995200 so you can see it converted instantly and tweak the value live.
How long ago (or how far away) is it?
The headline near the top of this page updates every time you load it, computing the gap between 1640995200 and your current clock in real time so it never goes stale. To measure the span between this timestamp and any other date precisely — in years, months, weeks, days, or business days — use the Date Duration Calculator. To watch a future moment tick down second by second, the Countdown Timer can target this exact instant.
Why timestamps matter
Storing time as a plain integer of seconds is wonderfully unambiguous: there is no time zone, no daylight saving, and no locale to misinterpret. Two servers anywhere on Earth agree on what 1640995200 means. That is why logs, databases, JWTs, file metadata, and APIs lean on Unix time so heavily. The trade-off is that the number is not human-friendly at a glance — which is exactly the gap a reference like this page fills.
Related timestamps
Other notable Unix timestamps worth a look:
- 1577836800 — Start of 20201600000000 — Round Timestamp 1.6 Billion1672531200 — Start of 20231700000000 — Round Timestamp 1.7 Billion