The negative leap second: the clock bug nobody has rehearsed in production

On 15 October 2026 the General Conference on Weights and Measures votes on Draft Resolution C, which would stop inserting leap seconds into UTC from 20 May 2027. As of 8 October the vote has not happened. The argument for it comes from software rather than astronomy: every one of the 27 leap seconds so far added a second, several still took down production systems, and the next one may have to delete a second, which no production fleet has ever lived through.

The forecasts for that deletion disagree, and the latest rotation data point away from it. The case for ending leap seconds does not need the forecast to be right. It rests on a modest probability multiplied by a failure mode nobody can rehearse.

Why UTC keeps getting patched by one second#

UTC ticks on atomic clocks. UT1 tracks the actual rotation of the Earth, which wanders. The IERS keeps the two within 0.9 s of each other and, when the gap grows, announces a leap second in Bulletin C, issued every January and July. Since 1972 every correction has gone the same way, because the Earth was running slow.

The drought is the Earth speeding up. Duncan Agnew's 2024 Nature paper and the Scripps release on it put numbers on it: in 1972 a rotational day ran 2.5 ms longer than an atomic day, and by 2023 the excess was down to 80 µs. Push past zero for long enough and UT1 drifts ahead of UTC. The fix for that is a negative leap second: 23:59:58 followed directly by 00:00:00.

Each positive leap second broke a different assumption#

The incidents share a date pattern and nothing else. Each one found a separate piece of code that had never seen a repeated second.

1. 31 December 2008

   Linux hard hangs

   ~53 reports on LKML

   Linas Vepstas collected the reports. Warner Losh, in the same thread, already used the phrase "negative leap second" for the opposite case.

2. 30 June 2012

   hrtimer CPU storm

   Reddit down 30–40 min, Qantas to manual check-in

   The kernel set CLOCK_REALTIME back a second but never called clock_was_set(), a call removed in 2007 to dodge a deadlock. Absolute futex timeouts returned instantly and loops spun until reboot.

3. 30 June 2015

   Early timers

   up to ~10 ms window, HZ-dependent

   The kernel applied the leap on the next timer tick rather than at the second edge, so timers in that window fired early. Cisco flagged a critical NX-OS bug.

4. 1 January 2017

   Cloudflare RRDNS

   ~0.2% of DNS queries at peak, 6 h 45 min

   A Go service measured resolver latency as a difference of two time.Now() values. Across the repeated second it went negative and rand.Int63n panicked.

The 2012 bug is the clearest. John Stultz's patch analysis reproduced it on kernels from 2.6.32 to 3.5-rc4 and traced it to commit 746976a301ac in 2.6.22. The airline outage came through Amadeus's Altea system, roughly 48 minutes by The Register's account. Press reports at the time also named Mozilla, Yelp and LinkedIn; none published a postmortem.

Cloudflare's own write-up is the canonical one, partly because the fix was one character: rttMax <= 0 instead of == 0. Russ Cox cited it in the monotonic time design doc, and Go 1.9 shipped in August 2017 with a monotonic reading inside every time.Time. The backward-step bug class got a language-level fix. Its mirror image never had to.

A deleted second jumps the wall clock forward#

The kernel's second_overflow() in ntp.c says it plainly: the insert state sets the clock back one second, the delete state sets it ahead. On a deletion CLOCK_REALTIME jumps +1 s, CLOCK_MONOTONIC does not move, and Unix time never takes the value for 23:59:59.

That flips which bugs fire, and this is analysis from the code rather than a reported incident. Cloudflare's negative duration cannot happen. In its place, any interval measured on the wall clock across midnight reads a full second too long. A positive number passes every <= 0 guard ever written. Deadlines computed as Date.now() + n expire a second early, so TTLs and leases are cut short. A scheduler that fires on now == target has no 23:59:59 to match, and a rate limiter keyed on the wall-clock second loses one window entirely. Log ordering survives: a deletion leaves a gap where an insertion leaves a duplicate.

NTP announces it with leap indicator 2, "last minute has 59 seconds", in RFC 5905. A 2026 operator guide claims LI=2 has never been sent in production, which fits the history but comes from a single weak source.

The big operators avoid the step entirely by smearing, and smearing a deletion means running clocks fast. Google says a negative leap second would be smeared "by speeding up clocks over the 86,399 SI seconds from noon to noon", roughly 11.6 ppm. CLOCK_MONOTONIC follows frequency adjustments, so for that day even monotonic durations run about a second fast per 24 hours: harmless for timeouts, visible to anything that measures ppm.

Google, AWS and chrony all say the same thing: do not mix smeared and unsmeared sources. Mid-smear the two disagree by up to about 0.5 s, and a stepped source disagrees by the full second at the end. Nothing in the NTP packet tells a client which kind of server it is talking to.

Nobody agrees the negative second is coming#

The headline date, "around 2029", is Agnew's 2024 estimate. His own later paper cut it to a probability, and the most recent rotation data look worse for the forecast.

The peak is fading. Malkin's page reports yearly-average day length turning positive for the first time since June 2020. If that holds, the vote ends leap seconds just as the case for a negative one weakens. The two are consistent: a 25% chance of an event with zero production history is the kind of risk timekeepers can remove by changing a rule instead of fixing code. Bulletin C 72, published on 6 July 2026, already rules out any leap second at the end of 2026.

What the vote changes, and what it leaves alone#

The 2022 Resolution 4 is often summarised as "leap seconds abolished by 2035". It only promised to raise the tolerance by then. Draft C would set the number, an hour, which the CCTF chose for "several centuries" of continuity, and pull the date forward from 2035 to 20 May 2027. Russia voted against in 2022 because GLONASS embeds leap seconds; its 2026 position is not public.

If Draft C passes, the step simply stops. Your existing code does not change, and TAI−UTC stays at 37 s. If it fails, nothing happens before January 2027 at the earliest, because the next possible leap second is 30 June 2027 and Bulletin C 73 has to announce it six months ahead.

Is there anything to check now?#

The useful checks do not depend on the outcome, and they overlap with the general case in why timestamps lie.

• Measure durations on a monotonic clock. In Node, process.hrtime.bigint() and performance.now(); Date.now() reads CLOCK_REALTIME and would jump +1000 ms on a deletion.
• In Go, keep the monotonic reading. Sub, Before and After use it, but Round, Truncate and AddDate strip it.
• Pick one smear policy per fleet. Mixing Google Public NTP with an unsmeared pool, or Amazon's NTP with its PTP clock, gives you a one-second disagreement by design.
• Grep for equality on wall-clock seconds. A scheduler or rate limiter that waits for an exact second is the code a deletion would skip.

// Node ≥10.7: hrtime.bigint() ignores clock steps; Date.now() does not.
const start = process.hrtime.bigint();
await doWork();
const elapsedMs = Number(process.hrtime.bigint() - start) / 1e6;

If you already do all four, you are unaffected either way. If you do none, a passed Draft C makes that moot from May 2027. A failed one leaves your code facing a deleted second that nobody has ever run it through.