Convert a Unix timestamp to a readable date in any time zone, or turn a date back into a timestamp. Seconds, milliseconds, microseconds and nanoseconds are detected automatically, and daylight saving changes are handled correctly.
The current Unix time
Loading the clock...
Timestamp to date
Date to timestamp
Read as a time in UTC. Change the zone above to read it somewhere else.
Convert a list at once
Timestamps use the unit chosen above. Dates without an offset are read in UTC.
Runs entirely in your browser. Nothing you type or upload is sent to a server.
What a Unix timestamp is
A Unix timestamp is a count of the seconds that have passed since 00:00:00 UTC on 1 January 1970, a moment known as the Unix epoch. At 1,700,000,000 it was 22:13:20 UTC on 14 November 2023. Because it is just a number, it sorts correctly, takes no time to compare and means the same thing on every computer in the world. That is why databases, log files, APIs and authentication tokens use it to record when something happened.
The date is close to arbitrary. The first edition of Unix, in 1971, counted sixtieths of a second from the start of that year, which would have run out in a little over two years. The count was changed to whole seconds and the starting point moved to a round date just before Unix existed, and it has stayed there since.
Seconds, milliseconds, microseconds and nanoseconds
The epoch is always the same, but systems disagree on what they count from it. The number of digits tells you which one you have:
| Unit | Digits today | Where you see it |
|---|---|---|
| Seconds | 10 | date +%s, PHP's time(), Go's Unix(), JWT exp and iat claims, most web APIs |
| Milliseconds | 13 | JavaScript's Date.now(), Java's System.currentTimeMillis(), many JSON APIs |
| Microseconds | 16 | Go's UnixMicro(), tracing systems, some database exports |
| Nanoseconds | 19 | Go's UnixNano(), InfluxDB, high-resolution event logs |
The converter reads anything below 100 billion as seconds, which covers every date up to the year 5138, and moves up a unit for every three extra digits. The rule fails for small millisecond values, such as a duration of 5000 ms, so the unit menu lets you override it. Nanosecond values are handled as exact integers. A 19-digit number is too large for an ordinary JavaScript number, and many converters quietly round its last digits away.
Time zones and daylight saving
A timestamp has no time zone. Turning it into a clock time needs the rules for a particular place, which come from the IANA time zone database built into your browser. Those rules change over history: before 1883, New York kept local solar time, 4 hours 56 minutes and 2 seconds behind Greenwich, and the converter shows that offset for old dates.
Going the other way is where mistakes happen, because a local time does not always name exactly one moment. At 2:00 am on 10 March 2024, clocks in New York jumped straight to 3:00, so 2:30 am that night never existed. On 3 November 2024 the clocks went back and 1:30 am happened twice, an hour apart. The date-to-timestamp section tells you when you have picked one of these times and shows what most software does with it.
Store moments as UTC timestamps and convert them for display. For a future event such as a meeting, store the zone name, such as America/New_York, rather than a fixed offset, because the offset depends on daylight saving rules that can change before the date arrives.
Date formats you will meet
ISO 8601, also called RFC 3339 on the internet, writes 2023-11-14T22:13:20Z. The Z means UTC, and an offset such as -05:00 can replace it. It sorts correctly as plain text and cannot be misread. RFC 2822 is the format of the Date line in every email, Tue, 14 Nov 2023 22:13:20 +0000, and HTTP headers use the same layout ending in GMT.
Typed dates are where conversions go wrong. JavaScript's own Date.parse reads 2024-03-15 as midnight UTC but 2024-03-15T00:00 as midnight local time, and guesses at anything else. This tool accepts only formats with one meaning and says which format it recognised. It refuses 03/04/2024 unless one number is over 12, because Americans read it as March and most of the world reads it as April.
The Year 2038 problem
Many older systems stored Unix time in a signed 32-bit integer, whose largest value is 2,147,483,647. That is 03:14:07 UTC on 19 January 2038. One second later the counter overflows to -2,147,483,648, which reads as 20:45:52 UTC on 13 December 1901. Current operating systems and languages use 64-bit time, which will not run out for billions of years, but the limit survives in file formats, embedded controllers and database columns. MySQL's TIMESTAMP type, for example, still ends at that second. The converter warns you whenever a value falls outside the 32-bit range.
Leap seconds
Unix time pretends every day has exactly 86,400 seconds. Since 1972, 27 leap seconds have been added to UTC to keep it in step with the Earth's rotation, and Unix time skips over each one, either by repeating a second or by stretching the seconds around it. For almost every purpose this is what you want, because it means a date can be computed from a timestamp with simple arithmetic. In 2022 the international timekeeping authorities voted to stop adding leap seconds by 2035.
Timestamps turn up inside other formats too. The JWT decoder reads the expiry claims in login tokens, the cron expression explainer shows when a scheduled job will next run, and the JSON formatter tidies the API responses they usually arrive in.
