Timestamp Converter

A Unix timestamp is a count of seconds since midnight UTC on 1 January 1970. That is all it is: one integer, no timezone, no calendar, no formatting. It is the most portable way to record an instant, and the least readable — which is why a log line saying 1700000000 sends everybody looking for a converter.

Paste a number here and it becomes a date in your own timezone and in UTC at the same time, plus ISO 8601 for pasting into code and a plain-English relative reading. The unit is detected from the magnitude and stated openly, so you can see whether it read your number as seconds or as milliseconds rather than having to guess from the answer.

It goes the other way too, and the current timestamp ticks at the top of the page for when you need one to test with.

Unix time is defined in seconds and that is what appears in a database column, in an HTTP Date computation and in a JWT's exp claim. Milliseconds are what JavaScript's Date.now, Java's System.currentTimeMillis and most application logs produce. Microseconds turn up in Postgres and ClickHouse; nanoseconds in Go's UnixNano and in Prometheus.

Because the plausible range of a real timestamp is narrow, the digit count separates them cleanly. Any date between 2001 and 2286 is ten digits in seconds, thirteen in milliseconds, sixteen in microseconds and nineteen in nanoseconds — no overlap, so the detection is reliable rather than a guess dressed up as one.

It stops being reliable near the epoch itself, where 5000 is equally plausible as five seconds or five milliseconds past midnight on 1 January 1970. That is the one case where you should set the unit yourself, and the tool says which way it went rather than deciding silently.

The timestamp has no timezone. It names an instant, and an instant is a different wall-clock reading in every zone at once — 1700000000 is 22:13 on the 14th in London and 03:43 on the 15th in Kolkata, and neither is more correct than the other.

This is why both are shown side by side. A bug report that says an event happened at the wrong time is usually a rendering problem rather than a storage one: the number is right and the zone it was displayed in was not.

The same asymmetry runs the other way. Converting a date to a timestamp has no single answer until you say which clock the date was read from, which is why the lower panel makes you choose. One further wrinkle: on the night the clocks go forward, some wall-clock times never happen at all, and a time inside that gap is moved forward to the next real instant rather than being rejected.

Timestamps before the epoch are negative. Minus 86400 is 31 December 1969, and the moon landing is around minus 14182940. Most languages handle this correctly, but a surprising amount of application code assumes a timestamp is positive, so a date of birth stored as Unix time is a reliable source of bugs. This converter accepts negative values and renders them normally.

At the other end, a signed 32-bit integer runs out at 03:14:07 UTC on 19 January 2038, and the next second wraps to December 1901. Anything modern uses 64 bits, which pushes the limit past the lifetime of the sun, but 32-bit time_t survives in embedded systems, in old file formats and in database columns that were declared decades ago and never widened.

The tool marks any value past that boundary, and the 2038 limit button jumps straight to it. If you are storing timestamps, store them as 64-bit integers or as a timestamptz column; if you are testing date handling, that instant and the leap day are the two values worth trying first.

It does not count leap seconds. Unix time treats every day as exactly 86,400 seconds, so on a day with a leap second the same timestamp value is used twice. This means the difference between two Unix timestamps is not quite the number of elapsed SI seconds — a discrepancy of 27 seconds has built up since 1972, and it matters for satellite tracking and for essentially nothing else.

It is also not a calendar. Working out someone's age, or what happens a month from now, needs real date arithmetic: months have different lengths, years have different lengths, and adding 30 days is not adding a month. Arithmetic on the raw integer is only safe for durations measured in seconds, minutes and hours.

Where it is exactly right is recording when something happened. A timestamp is unambiguous, sorts correctly, compares cheaply and survives being moved between systems that disagree about formatting — all the things a date written as text does not do.