Skip to content
AgileLogics

Unix Epoch Time Converter

Converts a Unix epoch timestamp to an ISO 8601 UTC date (seconds, or milliseconds for 13-digit values), or a date back to its Unix timestamp in seconds, stating the unit and time zone it used.

How it works

Enter a timestamp or date, choose a direction, and click Convert.

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

  1. Pick a Direction: Epoch → Date or Date → Epoch.
  2. Enter a timestamp in seconds (1700000000) or milliseconds (1700000000000), or a date (2024-01-01T00:00:00Z).
  3. 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:00Z is UTC and gives 1704067200 everywhere ("Time zone: UTC (from the Z suffix).").
  • 2024-06-01T09:30:00-04:00 carries its own offset and gives 1717248600 ("Time zone: UTC-04:00 (from the input).").
  • 2024-01-01 alone (date only) is treated as UTC midnight, 1704067200.
  • 2024-01-01 12:00 or 2024-01-01T00:00:00 with 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.750Z gives 1717234200.
  • Impossible dates and times are rejected: 2024-02-30 and 2023-02-29 give "is not a real calendar date", and 24:00 is 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

Last updated

Frequently asked questions

Is the timestamp in seconds or milliseconds?
Either. A value below 100000000000 is read as seconds, like the 10-digit 1700000000; anything from 100000000000 up, such as a 13-digit value from JavaScript's Date.now() or Java's currentTimeMillis(), is read as milliseconds. The second line of the result says which unit was used. Microseconds aren't detected: divide a 16-digit value by 1000 first.
What time zone is the result in?
UTC. Epoch to Date always returns ISO 8601 with a Z suffix, for example 2023-11-14T22:13:20.000Z, followed by a line confirming the unit and "Time zone: UTC". Unix time itself has no time zone; it counts seconds from 1970-01-01T00:00:00Z.
What date formats does Date to Epoch accept?
ISO 8601 is the safe choice: 2024-01-01T00:00:00Z for UTC or 2024-06-01T09:30:00-04:00 with an offset. A date-time without Z or an offset, like 2024-01-01 12:00, is read in your device's local time zone. Other text such as March 7, 2024 goes to your browser's date parser. Every result has a second line naming the time zone that was used, and impossible dates like 2024-02-30 are rejected.
Can I convert dates before 1970?
Yes. Timestamps can be negative: -86400 is 1969-12-31T00:00:00.000Z, and a date before 1970 converts to a negative number.
What is the year 2038 problem?
Systems that store Unix time in a signed 32-bit integer run out at 2147483647, which is 2038-01-19T03:14:07Z. One second later the value wraps to -2147483648, which reads as 1901-12-13T20:45:52Z. This converter uses 64-bit floating-point dates and isn't affected.