Convert Unix timestamps to dates and back

How to use it#

1. Copy the epoch time now from the live rows at the foot of the tool, if that is all you need.
2. Otherwise paste a timestamp or a date, or click Use current time to start from now.
3. If the number is close to 1970, set the unit rather than leaving it on Auto.
4. Pick a time zone to reread the same instant there, then copy the row you need. Type a city or letters such as EST or IST to find a zone.

Seconds, milliseconds, and how to tell them apart#

A Unix timestamp counts from midnight UTC on 1 January 1970. Unix itself, and most databases and APIs, count in seconds. JavaScript counts in milliseconds, which is the single most common cause of a date landing in 1970 or past the year 55,000. Some databases store microseconds, and Python’s time.time_ns(), Go’s UnixNano, and most tracing tools count in nanoseconds.

Length is the quick test. A current timestamp has ten digits in seconds, thirteen in milliseconds, sixteen in microseconds, and nineteen in nanoseconds. That rule holds from 2001 until 2286, which covers anything you are likely to be debugging. A decimal point is fine too: 1700000000.25, the kind of value Python’s time.time() returns, reads as seconds and a quarter.

The rule breaks for dates near the epoch itself, where a seconds value has far fewer digits and could plausibly be either. Auto detection here guesses by magnitude and gets it right for any modern date, but the unit is a setting you can override precisely because the guess is not always right.

A JavaScript date holds whole milliseconds, so the microseconds and nanoseconds in a finer timestamp would be lost on the way through one. When the number you paste is in either unit, rows for both appear under the milliseconds, worked out from the digits you typed rather than from the date, so all nineteen digits of a nanosecond value survive.

Why the readable time depends on where you are#

A timestamp has no time zone. It is a count of seconds since a fixed instant, and it means the same moment everywhere on earth. The zone only matters when you turn it into something a person reads, because that is when the clock on the wall gets involved.

The readable row shows the instant in the zone you pick, with the letters the zone goes by at that moment and its offset from UTC: 17:13:20 EST (UTC-05:00) in New York in November, EDT and UTC-04:00 in July. The zones are named places rather than fixed offsets, so daylight saving is applied for the date in question. Changing the zone changes nothing about the underlying value, which is why the Unix and ISO rows do not move. If a bug report and a log file disagree about when something happened, this is usually where the disagreement lives.

The zone also matters going the other way. A date typed without an offset, such as 2023-11-14 09:00, is a time on a clock somewhere, so it is read in the zone you have picked, and the Read as row says so. Pick Eastern and 09:00 is nine in the morning in New York. A date with a Z or an offset such as +05:30 already says where it is, and is read exactly as written whatever the zone.

ISO 8601 with a trailing Z is the safest thing to write down, because it is unambiguous and sorts correctly as plain text. A date written as 03/04/2023 is not, and which of March and April it means depends on who typed it.

The 2038 problem, briefly#

Systems that store a timestamp as a signed 32-bit integer run out of room on 19 January 2038, when the count exceeds 2,147,483,647 and wraps to a negative number near 1901. It is the same shape of problem as Y2K and it is still present in older embedded systems and some database columns.

Modern languages use 64-bit values and are unaffected. If you maintain something that stores epoch seconds in a 32-bit column, that column is the thing to find, and the fix is widening it rather than doing anything clever with the values already in it.