Unix timestamp

How it works

Unix time is the number of seconds since 1 January 1970 in UTC. The zero point was chosen because it sat conveniently close to when the measure was introduced, not because it means anything in itself.

The measure does not count leap seconds. A Unix day is always exactly 86,400 seconds, even on the days when UTC gained an extra second. That keeps the arithmetic simple, and Unix time still follows UTC’s dates and clock times. But the difference between two timestamps is not always the time that actually passed. Since 1972, 27 leap seconds have been added, and Unix time does not count them. For everything but satellite navigation it makes no difference.

The unit is guessed from the size of the number. Anything below ten billion is read as seconds, which lasts until the year 2286, and larger numbers as milliseconds or microseconds. The boundary sits there so that a year near the present is read correctly.

Negative numbers run back before 1970 and work the same way.

A signed 32-bit counter runs out on 19 January 2038 at 03:14:07 UTC, after which it wraps round to 1901. This is the year 2038 problem, the same kind of fault as the year 2000 problem but in binary. Systems counting in 64 bits are unaffected.

A date without a zone in the text is read as UTC, so the same text always gives the same number wherever it is read.

How the number is read

Spaces and underscores in the number are removed before it is read. With no unit chosen, size decides: below ten billion the number is read as seconds, from ten billion as milliseconds, and from one hundred trillion as microseconds. Those boundaries mean a millisecond value from before 26 April 1970, and a microsecond value from before 3 March 1973, are read in the wrong unit. Nanoseconds are not a unit: 1,757,000,000,000,000,000 nanoseconds, which is 4 September 2025, is read as microseconds and lands in the year 57647. Strip the last three digits in that case. Under the ECMAScript standard the browser’s calendar runs 100 million days either side of 1970, up to 13 September 275760, and numbers beyond that give an error message.

Worked example: where 32 bits run out

2³¹ − 1 = 2,147,483,647 is the largest number a signed 32-bit counter can hold. A second later such a counter holds −2,147,483,648, which the tool shows as 13 December 1901 at 20:45:52 UTC. Moments beyond those two limits get a warning: 2,147,483,648 triggers it, 2,147,483,647 does not.

Dates as text

In JavaScript, 2026-09-12T14:30 is read as local time but 2026-09-12 as UTC, under the ECMAScript standard. The tool reads both as UTC, so 2026-09-12T14:30 always gives 1,789,223,400. Fractions of a second are rounded down to the whole second.

Dates that do not exist are refused: 2026-02-30 gives an error message, whereas Date in V8, the engine in Chrome and Edge, silently turns it into 2 March. 24:00 is accepted as the end of the day, as ECMAScript allows.

Leap seconds and the time before 1970

POSIX defines seconds since the Epoch with a formula and states outright that the relationship to actual UTC is unspecified. ECMAScript says there is no time value for an instant within a leap second. So 2016-12-31T23:59:60Z, the most recent leap second, gives the error message that the time does not exist, while the second before gives 1,483,228,799 and the midnight after 1,483,228,800. According to the IERS, the difference between atomic time, TAI, and UTC was 10 seconds in 1972 and has been 37 seconds since 1 January 2017. IERS Bulletin C 72 announces that no leap second will be added at the end of December 2026.

For negative values POSIX leaves the relationship undefined. The tool follows ECMAScript, which counts backwards with the Gregorian calendar even before its introduction.

Sources

• POSIX.1-2024 (The Open Group) – 4.19 Seconds Since the Epoch
• ECMAScript Language Specification – Time Values and Time Range
• IERS – Bulletin C
• IERS – Leap_Second.dat (TAI–UTC since 1972)

How the tools are checked