Unix Timestamp Converter

Epoch to human time and back, across time zones, updating live.

Right now
Convert
Result

Enter a timestamp or a date above.

Send output to

Epoch time, and the two ways it goes wrong

Unix time counts the seconds since 1 January 1970 UTC. It is a single integer with no time zone, no locale and no ambiguity, which is why nearly every system stores time this way and only converts to a human calendar at the edges. Two failure modes account for almost every bug involving it.

Seconds against milliseconds

Unix, Postgres and most APIs speak seconds. JavaScript, Java and most JSON payloads produced by them speak milliseconds. Mixing them fails loudly in both directions: feed a seconds value to something expecting milliseconds and every date lands in January 1970, because you have divided the real instant by a thousand. Do the reverse and you end up somewhere past the year 57000.

Magnitude gives it away: a current epoch in seconds has 10 digits, in milliseconds 13. Detection is automatic here and you can override it, which matters for genuinely old timestamps where the digit count is ambiguous.

Time zones

The epoch value itself has no zone — it is an absolute instant. The zone only enters when you render it. That is why a bug report saying "the timestamp is off by five hours" almost never means the stored value is wrong; it means something rendered it in the wrong zone, usually the server's local zone rather than UTC.

Your local zone and UTC are shown side by side here for exactly this reason, along with the ISO 8601 form, which is the one to use in an API because it carries its offset explicitly.

2038

A signed 32-bit integer counting seconds overflows on 19 January 2038, wrapping to December 1901. Anything still storing time in a 32-bit time_t — embedded systems, old database columns, file formats that are not going to be updated — has a hard deadline. The conversion here uses JavaScript numbers and handles dates far beyond it, but the system you are debugging may not, which is worth checking whenever a date lands in 1901.

Everything is computed locally

Conversion uses the browser's own date handling. No request is made, which is also why the clock above is your machine's clock rather than a time server's.

Questions people actually ask

Seconds or milliseconds?
Detected automatically from magnitude — a 10-digit value is seconds, 13 digits is milliseconds — and you can override it. Mixing the two is the classic source of dates landing in 1970 or in the year 55000.
Which time zone is used?
Both. Your local zone and UTC are shown side by side, along with the ISO 8601 string, so you can paste whichever the system you are debugging expects.
What is the 2038 problem?
A signed 32-bit epoch overflows on 19 January 2038. Anything still storing time in a 32-bit int wraps to 1901. This converter uses JavaScript numbers, so it handles dates far past that — but the system you are debugging might not.
navigate open esc close