Heads up: posts on this site are drafted by Claude and fact-checked by Codex. Both can still get things wrong — read with care and verify anything load-bearing before relying on it.
why → how

Why leap seconds exist (and why they're being abolished)

The Earth doesn't spin on a schedule, but our clocks do. Leap seconds tried to bridge the two — and broke the internet doing it.

Science intro Apr 29, 2026 · updated Aug 25, 2026 · 9 min read

On this page

The picture version

Four pictures for a reader who has never met a 61st second. The prose below fills in the seams the pictures skip.

1 · The problem

Two clocks that were never going to agree.

atomic time — a counted, computed timescale the Earth’s rotation — measured by pointing radio telescopes at quasars tides, the core, the atmosphere — the planet is not a good clock, and not a predictable one Civil time has to follow the sun. So somebody patches the difference. that patch is a leap second, announced about six months ahead, and every one so far has added a second
Three timescales, not two: atomic time never adjusted, the Earth’s actual rotation wobbling, and civil time defined as the first with a running count of patches subtracted. As of 2026 that count is 37.

2 · Why software hates it

There is no room in the format for a 61st second.

23:59:60 legal in RFC 3339. not representable in time_t, which counts seconds since 1970 while ignoring leap seconds entirely. so every system picks one of three lies: repeat a second 23:59:59 happens twice pretend it didn’t happen and be a second off smear it run every clock slightly slow for hours There is no right answer, and that is itself the bug.
Different clouds, different OS versions and different time-daemon configs disagree by up to a second on what time it is during a smear window. Google published its smearing approach in 2011; AWS has offered smeared time to customers since 2017 — and the two need not agree.

3 · The seam nobody closed

You can track the Earth, or you can have every clock agree. Not both.

insert the second honestly civil time tracks the sun and you have emitted a timestamp much of your stack can’t store smear it away no discontinuity, no :60 and for hours your clock is wrong, differently from your neighbour’s No scheme keeps UTC near the Earth and keeps every clock agreeing. which is why the decision, in the end, was to stop trying
In 2022 the CGPM resolved to widen the allowed gap between civil and astronomical time by 2035, ending leap seconds in practice. A published draft resolution now proposes continuous UTC from 20 May 2027, with the tolerance widened to a full hour — to be voted at the 28th CGPM in October 2026. Draft, not yet decided.

4 · Keep this card

The whole thing on one index card.

leap second = atomic time + an occasional patch to keep civil time on the sun ∴ and the patch has no room in the format software uses
Picture to keep: a perfectly regular metronome and a slightly wobbly spinning top, and a person whose job is to nudge the metronome’s count every few years so the two still line up at midnight. The nudge is the leap second — and the trouble is that the notebook everyone writes the time in has no column for it.

Why it exists

If you counted down to midnight in London on 31 December 2016, the official countdown had an extra second in it. Not a rounding error, not a slow clock — an actual, deliberately inserted 61st second in the final minute of the year, agreed by an international body months in advance. Everyone shouting “three, two, one” was, briefly, counting against a minute that had 61 seconds in it — legal under the time standard, impossible in most software. That extra second is a leap second, and it exists because two definitions of “second” have been quietly drifting apart since 1967.

For most of human history “a second” was a fraction of a day, and a day was however long it took the Earth to spin once. That definition has a problem: the Earth is a wobbly, sloshing, slowing-down rock, not a metronome. Tides drag on it, the core moves, big earthquakes redistribute mass, the atmosphere shifts with the seasons. The length of a day jitters by milliseconds and, on a long enough timescale, gets gradually longer.

In 1967 the second was redefined as a fixed number of oscillations of a caesium-133 atom — exactly 9,192,631,770 of them. Suddenly “second” no longer meant “1/86400 of a day.” It meant a physical interval that atomic clocks could measure to absurd precision. Astronomical time (UT1) and atomic time (TAI) started to drift apart, because the Earth kept slowing down while the caesium kept ticking exactly the same.

The leap second was the compromise. Starting in 1972, UTC was defined as TAI minus a whole number of seconds, with an extra second occasionally inserted (almost always on June 30 or December 31) to keep UTC within 0.9 seconds of UT1. Civil time would stay aligned with the sun; atomic time would keep its precision; the leap second was the seam.

Why it matters now

Anyone who operates a fleet of machines has to have an answer to leap seconds right now: which NTP source your servers follow, whether that source smears or steps, and what happens to your logs, your ordering guarantees, and your certificate validity windows if two hosts disagree by a second. That’s not a hypothetical. Machines in different clouds, or on different NTP configs, genuinely disagree about what time it is during a leap-second window.

The famous demonstration: on June 30, 2012, a leap second was inserted, and a bug in the Linux kernel’s handling of it caused widespread hangs. Reddit, LinkedIn, Mozilla, and Qantas’s check-in system were among the visible casualties; the reports at the time attributed them to the kernel issue or to related problems in NTP daemons. What no one published afterwards was a tidy per-outage root-cause set, which is part of why the episode is remembered as folklore rather than as a documented incident class.

The problem is that a leap second is a kind of time event most software doesn’t know how to express. UNIX time is “seconds since 1970, ignoring leap seconds.” When a leap second arrives, the system either repeats a second (23:59:59 happens twice), pretends it didn’t happen, or “smears” it — slowing the clock for a few hours so the extra second is absorbed gradually. Google published its leap-smear approach in 2011 (and says it had been smearing internally before that); AWS offers smeared time to customers from 2017. There is no single right answer, which is itself the bug: different clouds, different OS versions, and different NTP configs disagree by up to a second on what time it actually is during the smear window.

In November 2022, the CGPM passed Resolution 4 of its 27th meeting: by or before 2035, the maximum allowed UT1 − UTC difference will be increased, which in practice ends leap seconds as we know them. What the new tolerance would be, and what replaced the correction, was explicitly left to the 28th CGPM. That meeting is scheduled for 13–15 October 2026, and BIPM has published a draft resolution proposing continuous UTC from 20 May 2027, with the tolerance widened to a full hour. Treat that as a published draft rather than a settled outcome — it has not been voted on.

The short answer

leap second = atomic time + an occasional patch to keep civil time aligned with the Earth's rotation

Picture to keep: two clocks side by side — one a flawless metronome, one a spinning top that’s very slowly winding down. A leap second is someone reaching over every few years and holding the metronome’s label back by one tick so the two never disagree by more than a second. (Where the picture breaks: nobody touches the metronome. The atomic clocks tick on undisturbed; what gets adjusted is the name we give the current instant, which is exactly why software chokes — a name can repeat, and a counter can’t.)

A leap second is an extra second inserted into UTC every few years to compensate for the Earth’s gradual slowing. It exists because we redefined “second” as an atomic unit but still wanted clocks to roughly agree with the sun.

How it works

The naive attempt: pick one clock. Either define time by the Earth’s rotation, or define it by caesium atoms. Both are defensible and both fail. Rotation-based time is measurable to remarkable precision — but it isn’t stable: the rate wobbles unpredictably, so you can’t use it as the reference interval for GPS, telecoms, or physics. Atom-based time is perfectly stable but says nothing about where the sun is — let it run for long enough and noon drifts off the middle of the day.

The fix: run both, and reconcile. Which is why there are three time scales, layered:

  1. TAI — atomic time, computed from a worldwide ensemble of atomic clocks and anchored so that it lined up with astronomical time at the start of 1958. Never adjusted afterwards. Monotonic, predictable, unphysical for everyday use because it doesn’t track sunrise.
  2. UT1 — astronomical time. Derived from very-long-baseline interferometry observations of distant quasars; tracks the Earth’s actual rotation. Wobbles unpredictably.
  3. UTC — civil time. Defined as TAI − N, where N is the cumulative count of leap seconds. As of 2026, N = 37. UTC is the timescale your phone and your servers are nominally keeping, even when what they display is local civil time.

The decision to insert a leap second is made by the IERS, usually about six months in advance, based on observed UT1 drift. Notably, every leap second so far has been a positive one (an extra second). The Earth has actually been spinning slightly faster than expected since around 2020, and serious discussion has happened about the possibility of a negative leap second — a second that gets deleted. No negative leap second has ever been scheduled, so that path has never run in production: the code exists in some standards and implementations and has never been exercised for real. Untested-by-construction is a strong argument for the change all by itself.

The mechanics on a Linux box on leap-second night, classically:

23:59:59 UTC
23:59:60 UTC   <- the leap second
00:00:00 UTC

23:59:60 is a legal timestamp in RFC 3339. It is not representable in time_t, and many database TIMESTAMP types and datetime libraries reject it too — a few standards-faithful implementations do accept it, which is its own kind of hazard when they exchange data with the ones that don’t. Hence the smear: instead of inserting a literal extra second, you spread its insertion across (say) 24 hours, running every clock 1/86400 slow. No discontinuity, no :60, but for that window your clock is wrong by up to half a second relative to UTC — and wrong in a different direction than your neighbor’s clock if they use a different smear window.

And the fix’s fix has its own failure. Smearing removes the illegal timestamp but replaces it with a period where machines honestly disagree about what time it is. That’s the seam nobody has closed: there is no scheme that keeps UTC within 0.9 s of the Earth’s rotation and keeps every clock in the world agreeing to the millisecond. The 2022 decision is the decision to stop trying — to let civil time drift from the sun rather than keep asking software to represent a 61st second.

Nobody has published a credible total for the industry cost of leap-second incidents, and most outage post-mortems frame the bug as a “kernel issue” rather than a “leap second issue” — so the cultural memory is fuzzier than the engineering record. The pattern that’s clear: leap seconds are a rare, untestable code path, and rare-untestable is exactly where bugs hide.

So — back to that London countdown. You started with leap second = atomic time + an occasional patch to keep civil time aligned with the Earth's rotation. What did this post add? — + and the patch is unrepresentable in the time format most software uses. UNIX time has no room for a 61st second, so every system has to lie about it in one of three incompatible ways. That’s the whole story of why an astronomy correction became an outage class.

Going deeper