Unix time is a calendar

The day counter hiding inside every computer. ← Calendar Contraptions

Unix time looks like the opposite of a calendar: just the number of seconds since midnight UTC on 1 January 1970, no months, no moons, no saints. But do the arithmetic and it gives itself away — divide by 86,400 and there is a plain count of days underneath. It is a calendar with a fixed day length written into it, an epoch chosen by a handful of engineers, 27 real seconds thrown away, and a cliff coming in 2038. This page is its user's manual.

Unix seconds

Unix day number

The POSIX day — what the counter pretends

The real UTC day — what the wall clock said

ISO week date

The week calendar rides along inside Unix time too — this row is piece 4's machine, fed from the same day count.

TAI − UTC at that moment

The 32-bit cliff

Traditionally time_t is a signed 32-bit integer, and a signed 32-bit integer stops at 2,147,483,647. Type any count — the box tells you what a 32-bit clock does with it, wrapping like the C code would.

A 32-bit clock reads

The 27 vanished seconds

#The 23:59:60 (UTC)TAI − UTC after

Round numbers worth a party

Unix people celebrate round counts of seconds the way everyone else celebrates new years. The readings below are computed from the numbers, not typed.

A calendar pretending to be a clock

The definition reads like a stopwatch: seconds since 00:00:00 UTC, 1 January 1970. The date itself was picked arbitrarily by Unix engineers for being convenient — and it wasn't even the first choice. The earliest Unixes counted 60 Hz hardware ticks from an epoch of 1 January 1971, then 1972, and the first edition's clock could only represent about two and a quarter years before overflowing. The third edition's manual states it flatly: storing the count in 32 bits "guarantees a crisis every 2.26 years." Counting seconds instead of ticks, from 1970, bought the range we still live in.

Look at how the count works and the calendar shows through. Divide by 86,400: the quotient is a day number, the remainder the time of day. Day 0 was a Thursday, and that is all the calendar arithmetic Unix time will ever need — no leap rule can touch the weekday, because Unix weeks never skip and no reform is coming for them: (day + 4) mod 7 picks the weekday for every instant the machine can name, forever. That is the same trick the Julian Day Number in piece 1 plays, minus the astronomy.

The subtlety is in the definition's fine print: Unix time counts non-leap seconds. When the POSIX committee had to decide what time_t should mean at a leap second, they chose the plain linear count — converting to civil time gets harder, but every arithmetic property survives. Computer clocks of the era were not steady enough to care. The bill for that choice arrives at every leap second, which is the next section's story.

The 27 vanished seconds

UTC keeps its date aligned with the Earth's rotation (a clock called UT1) by inserting a leap second at the end of 30 June or 31 December when the drift demands it. Since 1972 that has happened 27 times — all insertions, no removals — and the offset from atomic time now stands at TAI − UTC = 37 seconds: the 10 seconds UTC inherited from its pre-1972 rubber-second era, plus the 27. Unix time counts none of them. On a leap-second night the civil clock really shows 23:59:60 — the day underneath is 86,401 seconds long — but POSIX never has a 60th second to give: it repeats 23:59:59, one count for two different seconds, and the standard conversion interprets an ambiguous second as the time just after midnight.

Real software coped in real, incompatible ways. NIST's time servers freeze their count during the leap second. Google smears the extra second across 24 hours on its servers; Amazon picked a different smear — two correct machines, a second apart. And 1972 remains the longest year on record: 366 days, two of them a second longer than they should be, 31,622,402 seconds in all. No leap second has been inserted since 2016: the Earth has lately been spinning a little faster, which would normally call for the first negative leap second (never yet used) — one study attributes the postponement of that day to melting polar ice, which redistributes mass and slows the spin back down.

The contraption is scheduled for retirement. In November 2022 the General Conference on Weights and Measures resolved that the rules must change by 2035 — Russia pressed for 2040, because its GLONASS satellites broadcast leap seconds and GPS does not, so the change costs it more. The replacement (a wider tolerance, a smear, or a rare "leap minute") is expected at the 28th CGPM in October 2026. The table above is frozen at 27 rows; if the reform lands, this page's machine simply stops drifting from the count.

The 2038 cliff

One second past 2,147,483,647 — 03:14:07 UTC on Tuesday, 19 January 2038 — a signed 32-bit counter flips negative and a naive clock reads the result as 13 December 1901, 136 years in the past. (The overflow has picked up a nickname along the way: the Epochalypse.) Who still cares? Not most desktops and servers: 64-bit time_t has been standard there for years — NetBSD moved in 2012, OpenBSD in 2014, and most 64-bit systems never had the problem. A 64-bit second count is good for 292 billion years each way; Java and JavaScript count milliseconds instead and are good for 292 million years. The exposed systems are embedded ones — vehicles, routers, cameras — anything that keeps absolute dates on old 32-bit hardware. And it is not hypothetical: Microsoft Exchange's anti-malware update engine mapped a version stamp onto Unix seconds and broke on 1 January 2022, thirteen years early. The countdown above the cliff explorer is live.

Time zones are someone else's machine

Unix time is UTC-only — one number for the entire planet — and every time zone is a display detail bolted on at the edges. The part that knows about zones is the tz database: public domain, maintained by volunteers (Arthur David Olson wrote most of the code, Paul Eggert curates most of the data), and named after cities — America/New_York, Europe/Paris — because, as its own documentation notes, country names are not robust: political and boundary changes come too often. Cities last longer.

The database is where time-zone politics live in machine-readable form: Brazil's daylight-saving rule of 1963, which applied only in five states between 23 October and 9 December, is in there as a rule line. And zones change by decree. Samoa sat on the American side of the date line from 1892 — a switch made by repeating Monday, 4 July 1892, so Independence Day happened twice — then moved back in 2011 to share business hours with Australia and New Zealand, and the move was done by deleting a day: Friday, 30 December 2011 never existed in Samoa; Thursday the 29th was followed by Saturday the 31st. Tokelau crossed an hour later. Kiribati went the other way in the 1990s, pulling the date line east so its Line Islands sit at UTC+14 — Caroline Atoll was renamed Millennium Island for greeting the year 2000 first. Unix time noticed none of it: UTC+14 and UTC−11 are the same count to the machine. For two hours every day, three different calendar days are in use somewhere on Earth — and the day count underneath never wobbles.

What this page doesn't do

Everything here is UTC; your device's own zone never enters the math — that is not an oversight, it is the point of Unix time. The date picker is capped at 1800–2400 for sanity, but the seconds box and the cliff explorer accept far wider counts. The leap-second table is frozen data: the 27 announced insertions, the last on 31 December 2016 — nothing earlier is listed because before 1972 UTC's seconds were not SI seconds, so the atomic offset was not a whole number. The "real elapsed" figure is exact from 1972 on; before that it is approximate. And a classic trap the table cannot save you from: JavaScript's Date counts milliseconds — feed it a count of seconds and 2001-09-09 comes back as 12 January 1970.