Unix timestamp converter: epoch to date and back.

A Unix timestamp, also called epoch time or POSIX time, is the number of seconds that have passed since 00:00:00 UTC on 1 January 1970, the Unix epoch. 1700000000 is 22:13:20 UTC on 14 November 2023; 0 is the epoch itself; negative numbers count backwards to dates before 1970.

Unix time treats every day as exactly 86,400 seconds and ignores leap seconds. The 27 leap seconds added to UTC between 1972 and the end of 2016 do not appear in it, which keeps date arithmetic simple: subtract two timestamps and you have the seconds between them, give or take those rare leap seconds. No leap second has been added since 2016, and the decision to phase them out by 2035 means this edge case is fading.

A timestamp has no time zone. It names one instant that is the same everywhere on Earth, which is why it is the safest way to store and exchange moments in time. Time zones only matter when you display it, and that is the job this converter does for you.

The unit is the most common source of timestamp bugs. Timestamps in seconds have 10 digits for every date between September 2001 and November 2286. Milliseconds have 13 digits, microseconds 16 and nanoseconds 19.

Different platforms pick different units. JavaScript's Date.now() and Java's System.currentTimeMillis() return milliseconds. Python's time.time() returns seconds as a float, Go has time.Now().Unix() for seconds and UnixMilli() for milliseconds, PHP's time() and the shell's date +%s return seconds, and JWT exp and iat claims are in seconds by specification. Databases vary, so check the column documentation.

This converter reads any whole number with 13 or more digits as milliseconds and anything shorter as seconds, and says which it chose under the input. A 16-digit microsecond value would therefore be read as milliseconds and land tens of thousands of years in the future: divide it by 1,000 first. A 19-digit nanosecond value is outside the range JavaScript dates support, so divide by 1,000,000.

Conversion uses your browser's own date engine and its built-in copy of the IANA time zone database, the same data that operating systems and programming languages use. Every IANA zone your browser knows is in the list, from UTC to Asia/Kolkata, Asia/Dubai, Europe/London, America/New_York, Australia/Sydney and Pacific/Auckland, with the correct daylight-saving offset for the exact instant shown.

For each input you get Unix seconds and milliseconds, ISO 8601 in UTC, ISO 8601 in the chosen zone with its offset, the HTTP date format from RFC 9110 used in headers such as Last-Modified, a long readable date and a relative time such as '3 hours ago'. The right-hand panel works in reverse: a date and time you enter is read as wall-clock time in the chosen zone and converted to Unix seconds, milliseconds and UTC.

Nothing is sent to a server, so you can paste timestamps from production logs or tokens without them leaving your device. If you are reading token expiry times, the JWT decoder converts exp, iat and nbf claims for you.

A date in January 1970 almost always means seconds were passed where milliseconds were expected: new Date(1700000000) in JavaScript is 20 January 1970, while new Date(1700000000 * 1000) is November 2023. A date tens of thousands of years ahead is the opposite mistake.

A result that is off by a whole number of hours usually means a time zone was applied twice, or a local time was stored as if it were UTC. One hour off for part of the year points to daylight saving. The fix is the same in every language: store and transmit UTC, either as a Unix timestamp or as ISO 8601 with a Z or an explicit offset, and convert to local time only at the moment you display it.

Watch date strings without an offset. In JavaScript a date-only string such as 2026-10-10 is parsed as UTC midnight, but a date-time such as 2026-10-10T09:30 is parsed as local time on whichever machine runs the code. Always include Z or an offset like +05:30 in APIs, logs and the REST APIs you design.

Systems that store Unix time as a signed 32-bit integer can count up to 2,147,483,647, which is 03:14:07 UTC on 19 January 2038. One second later the value overflows to -2,147,483,648 and the date jumps back to 13 December 1901. It is the Unix equivalent of the Y2K bug.

Modern 64-bit operating systems, languages and databases use 64-bit time and are safe for billions of years; JavaScript dates run to the year 275,760. The risk sits in older embedded devices and firmware, 32-bit builds, binary file formats and database columns. For example, MySQL documents its TIMESTAMP column type as ending at 2038-01-19 03:14:07 UTC, so long-lived dates such as contract end dates or certificates belong in DATETIME or a 64-bit integer instead.

Testing is straightforward: paste 2147483647 and 2147483648 above to see the boundary, then feed dates after 2038 through your own system, including any scheduled jobs. The cron expression explainer helps you check when those jobs actually run.

ISO 8601 is the international standard for writing dates and times, such as 2026-10-10T09:30:00Z. RFC 3339 is a stricter internet profile of it that requires a full date, a full time and a Z or numeric offset, and it is what most JSON APIs mean when they say 'ISO date'. The ISO 8601 strings this converter produces are valid RFC 3339.

HTTP headers use a different, older format defined in RFC 9110, for example Sat, 10 Oct 2026 09:30:00 GMT, always in GMT. Logs often use Unix seconds for compactness and sorting. Pick one canonical format per system, document it, and convert at the edges.