Convert a Unix timestamp to a date

How it works

A Unix timestamp is one integer: how many seconds have elapsed since midnight UTC on 1 January 1970. That is the entire format. There is no zone inside it, no offset, no calendar and no text, and that emptiness is the reason programs store dates this way. Two machines on opposite sides of the planet holding the same integer hold the same instant, with nothing left to disagree about. A zone arrives only at the moment somebody renders the number for a person to read, and rendering is a display choice that leaves the value untouched.

Ten digits, thirteen digits, or nineteen

The same instant has four common spellings. Written in seconds the count is ten digits and will stay ten digits until 2286; in milliseconds it is thirteen, in microseconds sixteen, in nanoseconds nineteen. Nothing inside the number says which, and guessing wrong is not a near miss: read milliseconds as seconds and the answer lands over fifty thousand years out. Size is the only available clue, and it works because the plausible ranges barely overlap. Anything under 1e11 is taken here as seconds, under 1e14 as milliseconds, under 1e17 as microseconds, and above that nanoseconds.

Every heuristic has a seam, and this one is worth naming instead of hiding. The line between seconds and milliseconds sits at 1e11, which as a count of seconds is November 5138 and as a count of milliseconds is 3 March 1973. Below that line both readings are plausible, so a millisecond timestamp from before March 1973 gets read as seconds and lands in the far future. That is the single case size cannot resolve, and the unit control is there to settle it by hand.

The cliff in January 2038

For decades the C type holding this number was a signed 32-bit integer, which stops at 2,147,483,647. That count of seconds runs out at 03:14:07 UTC on 19 January 2038, and one second later the sign bit flips: the value goes negative and the date becomes 13 December 1901. Nothing throws. Sorting breaks, expiry checks invert, and anything comparing two dates starts answering backwards. Sixty-four bit time is the fix and most systems have taken it, but embedded firmware, old file formats and database columns typed as a 32-bit integer are all still out there counting.

Not a count of elapsed seconds

Unix time looks like a stopwatch reading and is nothing of the kind. It is defined as though every day holds exactly 86,400 seconds, and some days do not: the earth slows unevenly, so 27 leap seconds have been inserted since 1972 to keep clocks in step with rotation. Unix time skips all of them. The gap between two of these numbers therefore falls short of the true elapsed SI seconds by however many leap seconds fell between. During an inserted second the value repeats or freezes, depending on the system. Ordinary durations are unaffected; physics and finance are not, which is what TAI is for.

Numbers below zero

Nothing in the definition requires the value to be positive, and dates before 1970 are ordinary: -1 is 23:59:59 on 31 December 1969, and -2208988800 is the start of 1900. Plenty of software refuses them regardless, treating the epoch as a floor rather than an origin, which is how a birth date from the 1950s turns into 1 January 1970 in a badly written form. Older instants carry an oddity of their own, because a zone that predates standard time runs on local solar time and its offset holds seconds rather than whole minutes. Dublin was 25 minutes and 21 seconds behind UTC.

Where the precision runs out

A count of milliseconds stays exact in a double until 2^53 of them have passed, and that is a long way off. The nearer ceiling belongs to the date type itself, which stops 8.64e15 milliseconds either side of the epoch, in September 275760. Move to finer units and the ceiling drops hard: 2^53 microseconds after the epoch is June 2255, and 2^53 nanoseconds is 15 April 1970. A nanosecond timestamp read into a double is wrong in its last four digits from the day it was written, so the arithmetic behind this page runs on exact integers and narrows only at the end.

The clock here does not tick

Reading the current timestamp is the most common reason to open a page like this, so it sits on every answer. It is a snapshot rather than a clock: the number is taken at the instant the answer is worked out and then stays put until something prompts another one. Change any field, or add and remove a character in the box, and the reading refreshes. A frozen number animated to look live would be worse than a still one shown honestly.