Unix Timestamp Converter
Convert a Unix epoch timestamp to a human date, or a date back to a timestamp.
ISO 8601: 2023-11-14T22:13:20.000Z
- Local time
- Loading local time…
- Milliseconds
- 1700000000000
A Unix timestamp is the number of seconds since the epoch, 1970-01-01 00:00:00 UTC. To decode one, add those seconds to the epoch: 1700000000 seconds is Tue, 14 Nov 2023, 22:13:20 UTC. Divide milliseconds by 1000 first, since epoch time is normally counted in whole seconds.
What a Unix timestamp is
Unix time — also called epoch time or POSIX time — is a single integer that counts the seconds elapsed since 00:00:00 UTC on 1 January 1970, the “Unix epoch”. Because it is one number tied to UTC, it is unambiguous across time zones: the same instant has the same timestamp everywhere, with no date format, month names, or daylight-saving offsets to interpret. That makes it the standard way computers store and exchange moments in time.
Some systems store the value in milliseconds instead of seconds — JavaScript’s Date.now() is the common example. A milliseconds value is 1000× larger, so use the toggle above to match your source before converting.
For a milliseconds value, divide by 1000 first (or add the milliseconds directly).
- 1 Identify the unit. A 10-digit value near 1.7 billion is seconds; a 13-digit value is milliseconds. 1700000000 is 10 digits, so it is seconds.
- 2 Convert to milliseconds if needed. Multiply seconds by 1000: 1700000000 × 1000 = 1700000000000 ms.
- 3 Add the offset to the epoch. Counting that many seconds forward from 1970-01-01 00:00:00 UTC lands on 14 November 2023.
- 4 Read the result. 1700000000 = Tue, 14 Nov 2023, 22:13:20 UTC. The tool also shows the same instant in your local time zone.
Timestamps worth knowing
Second and millisecond forms of the same instant differ by a factor of 1000.
| Timestamp (seconds) | UTC date and time | Note |
|---|---|---|
| 0 | 1970-01-01 00:00:00 | The Unix epoch — where counting starts |
| 1000000000 | 2001-09-09 01:46:40 | The one-billion-second milestone |
| 1700000000 | 2023-11-14 22:13:20 | The example used on this page |
| 2147483647 | 2038-01-19 03:14:07 | Largest value a signed 32-bit integer holds |
| 4102444800 | 2100-01-01 00:00:00 | Start of the year 2100 (UTC) |
Seconds vs milliseconds, and the year 2038 problem
Getting the unit right. The most common mistake is mixing seconds and milliseconds. If a decoded date lands in 1970 you likely fed a seconds value into a milliseconds slot; if it lands tens of thousands of years in the future you did the reverse. As a quick check, present-day timestamps in seconds have 10 digits and in milliseconds have 13.
The 2038 problem. Older software stores Unix time in a signed 32-bit integer, which overflows at 2147483647 — 03:14:07 UTC on 19 January 2038. Past that point such a counter wraps around to a negative number and misreads the date as December 1901. Modern systems use 64-bit integers, which push the limit roughly 292 billion years out, so the fix is to store the value in a wider type.