What is a Unix timestamp?
A Unix timestamp, or epoch time, is the number of seconds since 00:00:00 UTC on 1 January 1970, ignoring leap seconds. 0 is that instant, 1700000000 is 2023-11-14 at 22:13:20 UTC, and negative values count backwards to dates before 1970. This converter turns a timestamp into a readable UTC date, or a date into a timestamp.
POSIX calls this "Seconds Since the Epoch" and defines it with a formula that treats every day as exactly 86,400 seconds (The Open Group Base Specifications, section 4.16). Leap seconds are simply not counted, so a Unix timestamp is not a true count of elapsed SI seconds, but every day is the same length, which makes date arithmetic easy.
Converting in either direction
- Pick a Direction: Epoch → Date or Date → Epoch.
- Enter a timestamp in seconds (
1700000000) or milliseconds (1700000000000), or a date (2024-01-01T00:00:00Z). - Click Convert.
Epoch → Date output is an RFC 3339 / ISO 8601 string in UTC, always with milliseconds and a Z, followed by a line saying how the number was read:
2023-11-14T22:13:20.000Z
Read as seconds. Time zone: UTC.
Date → Epoch output is a whole number of seconds, followed by a line naming the time zone the date was read in.
Seconds, milliseconds, microseconds
The single most common mistake is pasting a millisecond timestamp. This tool catches it: any value of 100000000000 or more (or -100000000000 or less) is read as milliseconds, because as seconds it would be past the year 5138. So 1700000000000 gives 2023-11-14T22:13:20.000Z with the note "Read as milliseconds", the same instant as 1700000000 in seconds.
| Digits (today) | Unit | Typical source | What the tool does |
|---|---|---|---|
| 10 | seconds | date +%s, PHP time(), most databases and APIs |
reads it as seconds |
| 13 | milliseconds | JavaScript Date.now(), Java System.currentTimeMillis() |
reads it as milliseconds |
| 16 | microseconds | some database and tracing tools | reads it as milliseconds, so drop the last 3 digits first |
The cut-off works on size, not digit count. Small millisecond values from early 1973 or before (below 100000000000) are read as seconds, so check the unit line if you're converting test data near 1970.
Decimal points aren't accepted either. Python's time.time() returns something like 1700000000.123456; keep only the part before the point.
Timestamps worth recognising
| Timestamp | UTC date |
|---|---|
0 |
1970-01-01T00:00:00Z |
946684800 |
2000-01-01T00:00:00Z |
1000000000 |
2001-09-09T01:46:40Z |
1234567890 |
2009-02-13T23:31:30Z |
2000000000 |
2033-05-18T03:33:20Z |
2147483647 |
2038-01-19T03:14:07Z |
4102444800 |
2100-01-01T00:00:00Z |
Every value here was produced by the converter itself.
The 2038 limit
Older C code and file formats store time in a signed 32-bit integer, which tops out at 2147483647. Convert that number and you get 2038-01-19T03:14:07Z. Add one second on such a system and the value overflows to -2147483648, which this converter shows as 1901-12-13T20:45:52Z. That jump back to 1901 is the year 2038 problem. Modern 64-bit operating systems use a 64-bit time_t, but embedded devices, old databases and binary file formats can still carry 32-bit fields.
This tool isn't limited to 32 bits. It uses JavaScript dates, which cover 8.64 quadrillion milliseconds either side of 1970 (ECMAScript time range). Seconds up to 99999999999 (the year 5138) convert directly, and larger values are read as milliseconds up to 8640000000000000, which is +275760-09-13T00:00:00.000Z; beyond that you get "That timestamp is out of range."
How Date → Epoch reads your input
ISO 8601 dates are read by the tool itself, and the second line of the result always says which time zone it used:
2024-01-01T00:00:00Zis UTC and gives1704067200everywhere ("Time zone: UTC (from the Z suffix).").2024-06-01T09:30:00-04:00carries its own offset and gives1717248600("Time zone: UTC-04:00 (from the input).").2024-01-01alone (date only) is treated as UTC midnight,1704067200.2024-01-01 12:00or2024-01-01T00:00:00with no zone is read as local time, so the result depends on where your device thinks it is. The note names it, for example "Time zone: your device's local time, UTC+05:00 (no zone in the input; add Z for UTC)."- Fractional seconds are rounded down:
2024-06-01T09:30:00.750Zgives1717234200. - Impossible dates and times are rejected:
2024-02-30and2023-02-29give "is not a real calendar date", and24:00is refused as an hour.
Other formats like March 7, 2024 or Tue, 14 Nov 2023 22:13:20 GMT are handed to your browser's Date parser. Those without a zone are read as local time, and the note says so; impossible days such as February 30, 2024 are still rejected. They aren't standardised, so prefer ISO 8601. Pasting a bare number into Date → Epoch gives "Enter a valid date"; switch the direction instead.
Related tools
- The time zone converter shows a UTC result in another city's local time.
- The date calculator adds or subtracts days without timestamp arithmetic.
- The countdown calculator shows the time left until a date, such as the 2038 rollover.
- The random date generator produces test dates to convert.
Last updated