Convert a Unix timestamp to a human-readable date, or turn any date and time back into epoch seconds. Seconds and milliseconds are detected for you, and every result is shown in both UTC and your local timezone.
Paste a timestamp in seconds or milliseconds — the unit is detected for you.
Enter a Unix timestamp.
Pick a date and time — entered in your local timezone, converted to epoch seconds.
Pick a valid date and time.
—
Ticking once loaded.
A Unix timestamp is a single integer: the number of seconds elapsed since 00:00:00 UTC on 1 January 1970, the moment known as the Unix epoch. Because it is one number anchored to UTC, it carries no timezone, no daylight-saving rules and no formatting ambiguity — which is exactly why systems store time this way and convert to a display format only at the edges.
Unix time deliberately ignores leap seconds. Each day is treated as exactly 86,400 seconds, so a timestamp is not a true count of elapsed SI seconds since 1970 — it is a count of days-times-86,400 plus the seconds into the current day. That simplification is what makes conversion arithmetic rather than a table lookup.
The most common conversion mistake is feeding a millisecond value into something expecting seconds, which lands you roughly 50,000 years in the future. Digit count tells them apart at a glance for any present-day date:
| Digits | Unit | Example | Resolves to |
|---|---|---|---|
| 10 | Seconds | 1771286400 | 2026-02-17T00:00:00Z |
| 13 | Milliseconds | 1771286400000 | 2026-02-17T00:00:00Z |
Whether you get seconds or milliseconds depends entirely on the runtime you pulled the value from:
The same instant is written many ways depending on the standard involved. Each of these is 17 February 2026 at midnight UTC:
| Format | Example | Where you meet it |
|---|---|---|
| Unix seconds | 1771286400 | Databases, APIs, log lines |
| ISO 8601 / RFC 3339 | 2026-02-17T00:00:00Z | JSON APIs, config, logs |
| ISO 9075 | 2026-02-17 00:00:00 | SQL timestamp columns |
| RFC 7231 | Tue, 17 Feb 2026 00:00:00 GMT | HTTP headers |
| RFC 2822 | Tue, 17 Feb 2026 00:00:00 +0000 | Email headers |
| Date only | 2026-02-17 | Report filenames, date pickers |
A timestamp is always UTC. The timezone enters only when you format it for a human, which is why the same timestamp legitimately renders as two different wall-clock times on two machines. Convert late, store early: keep the integer, and apply a timezone at the moment of display.
The other limit worth knowing is the year 2038 problem. A signed 32-bit integer overflows at 2,147,483,647 seconds, which arrives at 03:14:07 UTC on 19 January 2038; systems still storing time in a 32-bit signed field wrap to 1901 at that instant. Modern platforms use 64-bit time, but embedded devices and old on-disk formats remain the place to check.
A Unix timestamp is the number of seconds that have elapsed since 00:00:00 UTC on 1 January 1970, the Unix epoch. It is a single integer anchored to UTC, so it encodes an exact instant without any timezone or formatting ambiguity.
Paste the timestamp into the converter above and it returns the date in ISO 8601, UTC and your local timezone at once. In code: JavaScript uses new Date(seconds * 1000), Python uses datetime.fromtimestamp(seconds, tz=timezone.utc), and the shell uses date -d @seconds.
Count the digits. A present-day timestamp in seconds has 10 digits; in milliseconds it has 13. Anything 11 digits or longer is almost certainly milliseconds — reading it as seconds would place the date tens of thousands of years in the future.
UTC, always. A timestamp has no timezone of its own — the offset is applied only when the value is formatted for display, which is why one timestamp can correctly show as two different local times on two machines.
A signed 32-bit integer maxes out at 2,147,483,647 seconds, which is reached at 03:14:07 UTC on 19 January 2038. Systems that still store Unix time in a 32-bit signed field will overflow and wrap around to 1901. 64-bit time values push the limit far beyond any practical horizon.
No. Unix time treats every day as exactly 86,400 seconds and simply repeats or skips a value when a leap second occurs, so it is not a true count of elapsed SI seconds since 1970. That trade-off is deliberate: it keeps conversion to a calendar date pure arithmetic.
Yes. Negative timestamps represent instants before the epoch — -86400 is 31 December 1969. Support varies by platform, and some older systems and databases reject negative values outright, so dates before 1970 are worth testing rather than assuming.