Skip to content
Published on

No Leap Second in 2026 — and the Negative One No System Has Ever Run

🇰🇷KO🇺🇸EN🇯🇵JA
Split View필사 모드
Share
Authors

Introduction — Leap Seconds, UTC, TAI, and Earth's Wobble

Most developers write code assuming time "just flows uniformly." But the UTC we use is a compromise between two different kinds of time. One is International Atomic Time (TAI), measured by atomic clocks, which emits perfectly uniform seconds. The other is UT1, defined by Earth's rotation — and Earth wobbles and changes its spin rate because of tidal friction and internal motion.

UTC ticks with TAI's uniform seconds, but occasionally inserts one second so it never drifts more than 0.9 seconds from UT1. That inserted second is the leap second. A positive leap second looks like this — the last minute of the day becomes 61 seconds long:

Positive leap second:   23:59:58 → 23:59:59 → 23:59:60 → 00:00:00

The seed of the problem is right here. The instant 23:59:60 genuinely exists, but as we will see, Unix time has no place to store it. Since their introduction in 1972, 27 leap seconds have been inserted, all positive. The last was 31 December 2016. As a result TAI - UTC = 37 s today, or equivalently UTC - TAI = -37 s.

2026: No Leap Second — and the First-Ever Negative One

On 6 July 2026, in Paris, the IERS issued Bulletin C 72. The essence is a single line:

IERS Bulletin C 72 — Paris, 06 July 2026
"NO leap second will be introduced ... at the end of December 2026."
UTC - TAI = -37 s   (unchanged since 2017-01-01)

So there is no leap second in December 2026 (nor was there one at the end of June). That is years now with no adjustment at all — and here is why it is not quiet news. Around 2016, Earth's rotation started to speed up instead. If it keeps accelerating and UT1 pulls ahead of UTC, then one day a second must be removed from UTC to catch up. That would be the first-ever negative leap second.

A negative leap second is the exact opposite: it deletes a second. The last minute of the day becomes 59 seconds long.

Negative leap second:   23:59:58 → 00:00:00        (23:59:59 removed)

All 27 leap seconds so far have been positive; the negative case exists only in the specification and has never been applied anywhere on Earth. Patrizia Tavella, who directs the Time Department at the BIPM, estimated that "if we wait till 2035, we have 30 percent risk of a negative leap second." Meanwhile, the 2022 CGPM Resolution 4 decided to effectively abolish leap seconds "in, or before, 2035" and let the UT1-to-UTC tolerance grow much larger, with the new limit to be set at the 28th CGPM in October 2026. But that decision does not remove the risk that remains before 2035.

Why This Is a Distributed-Systems Problem — POSIX Time, NTP, and the Lessons of 2012 and 2017

The definition of Unix time is simple: unix time = (days since epoch) × 86400 + seconds of that day. In other words, it hard-codes "a day is always 86400 seconds." So there is no slot for 23:59:60.

  • For a positive leap second, Unix-family systems usually repeat that second or step the clock back by one. Time goes backward, or the same timestamp appears twice (non-monotonic).
  • For a negative leap second, the timestamp skips a slot. Time still only moves forward, but the Unix value that would be 23:59:59 maps to no real instant at all — a one-second "hole."

We have already seen what happens when that assumption breaks. At the 1 July 2012 leap second, a Linux kernel timer (hrtimer) bug caused a livelock that pinned CPUs at 100%; Reddit, Mozilla, and others were hit, and an outage in the Amadeus airline reservation system delayed some Qantas flights. Most operators recovered by restarting NTP or resetting the clock.

When the 31 December 2016 leap second landed at midnight, Cloudflare's DNS resolver, written in Go, assumed "time only ever moves forward," subtracted two timestamps, and got a negative interval; that value fed a random-range calculation and made a fraction of DNS queries error out. Cloudflare published the postmortem.

Both incidents share one root cause — code that believed "time flows uniformly and monotonically." Here is the twist. Because a negative leap second jumps time forward, it does not produce the 2017 Cloudflare-style "negative interval" bug at all (monotonicity is preserved). Commenters on the HN thread noted that "jumping forward a second won't lead to a time loop like jumping back did." The real problem is different: the negative-leap-second path has never once executed in any production system. "Sixty seconds in a minute," hard-coded leap-second tables that only ever assume +1, and smear logic run in reverse (clock slightly fast) are all unexercised code.

NTP is no better off. Google, Amazon, and Meta each "smear" the second across a window so it disappears (Google and AWS spread it over 24 hours), and applications never see 23:59:60. But the window length and curve differ per vendor, and mixing a smeared server with an unsmeared one in the same fleet makes clocks disagree. For a negative leap second, the smear must run the clock slightly fast to reclaim a second — and that, too, has never run at scale.

Closing — What Engineers Should Check Now

  • Know how your platform handles leap seconds — step, repeat, or smear. The whole fleet should use the same approach, and never mix smeared and unsmeared NTP.
  • Measure durations and timeouts with a monotonic clock (CLOCK_MONOTONIC), not the wall clock (CLOCK_REALTIME). The 2017 Cloudflare bug was exactly a wall-clock subtraction.
  • Do not hard-code "60 seconds per minute," "86400 seconds per day," or "leap seconds are always +1."
  • Do not rely on wall-clock timestamps for ordering, uniqueness, or sequencing — use logical clocks, a monotonic source, or a TrueTime-style interval.
  • Test it. You can simulate a negative leap second by making the clock actually skip a slot. Most organizations have never done it once.

To be honest, nothing happens in December 2026 (no leap second). The point of this piece is not fear but preparation. Earth's rotation has already changed direction, and one day — probably before 2035 — the whole planet will step, simultaneously, through a code path that has never executed. Before then, it is worth hunting down the code that trusts the wall clock.

References

Discuss on Twitter • View on GitHub