Leap seconds are set to end May 20, 2027, before the first negative leap second
Contents
The 27th CGPM (General Conference on Weights and Measures) resolved in November 2022 to abolish the leap second by 2035, and Draft Resolution C, published in January 2026, proposes May 20, 2027 as the effective date.
The vote happens at the 28th CGPM, which opens in Versailles on October 13, 2026.
The reason for moving eight years ahead of the 2035 deadline is the negative leap second.
Earth’s rotation has been speeding up, and the probability that a second will need to be removed is put at 30% by 2035.
A negative leap second has never been applied since the system started in 1972.
How leap seconds work
| Time scale | Based on | Behavior |
|---|---|---|
| TAI (International Atomic Time) | accumulated atomic clock time | ticks at a constant rate |
| UT1 (Universal Time) | measured Earth rotation | drifts with the rotation |
| UTC (Coordinated Universal Time) | TAI ticks + leap seconds | kept close to UT1 |
UTC ticks at the same rate as TAI, and a second is inserted or deleted so that its difference from UT1 never reaches 0.9 seconds.
As NICT’s explainer lays out, IERS (International Earth Rotation and Reference Systems Service) in Paris decides whether an adjustment is needed.
IERS issues a notice called Bulletin C every six months, announcing whether a leap second goes in at the end of the coming June or December.
All 27 insertions so far added a second.
The offset from TAI started at 10 seconds and stands at 37 seconds after those 27 insertions.
In Japan, NICT applies the leap second to Japan Standard Time.
The last one went in on January 1, 2017, as 8:59:60 between 8:59:59 and 9:00:00 JST.
Leap years can be computed mechanically from the Gregorian calendar rules, but leap seconds come from measured Earth rotation.
Whether the next one happens is unknown until Bulletin C, six months ahead.
How the end was decided
The General Conference on Weights and Measures, the body that also maintains the definitions of the metre and the kilogram, decided to end the leap second.
Resolution 4 of the 27th meeting in November 2022 set out that the maximum allowed UT1-UTC difference will be raised in or before 2035.
Insertions happen at one-second granularity because the cap sits at 0.9 seconds.
Widen the cap far enough and insertions stop.
The 2022 resolution named no new cap.
It fixed only that the value must keep UTC continuous for at least a century, and that the CIPM (International Committee for Weights and Measures) propose the value and an implementation plan to the next meeting.
That proposal was published as Draft Resolution C on January 13, 2026.
The cap is 3600 seconds (one hour), which keeps UTC continuous for several centuries.
The effective date of May 20, 2027 was set in a January 30 revision.
The 28th CGPM meets in Versailles on October 13-15, 2026, and votes on it.
| When | What |
|---|---|
| 1972 | Current UTC scheme starts. 10 seconds behind TAI |
| December 31, 2016 | 27th insertion. Offset from TAI reaches 37 seconds |
| November 2022 | 27th CGPM resolves to raise the cap by 2035 |
| January 2026 | Draft Resolution C published. 3600-second cap, May 20, 2027 start |
| October 2026 | 28th CGPM votes on Draft Resolution C |
| May 20, 2027 | If adopted, continuous UTC without leap seconds takes effect |
Abolition does not abolish UTC itself.
Insertions stop, and the gap to UT1 is allowed to grow.
If Draft Resolution C is adopted in October, BIPM (International Bureau of Weights and Measures), IERS, and time distribution services work toward the May 20, 2027 start.
Outages leap seconds have caused
Behind the abolition sits a track record of outages at each insertion.
At the June 30, 2012 insertion, Reddit went down for 30 to 40 minutes.
According to Meta’s engineering blog, the time change confused the Linux kernel’s high-resolution timer (hrtimer) and machines locked up with their CPUs maxed out.
Wired’s coverage at the time has Mozilla, Gawker, Foursquare, Yelp, LinkedIn, and StumbleUpon reporting trouble as well.
Gawker’s Tomcat web servers went nearly unresponsive, and only reboots brought them back.
At the January 1, 2017 insertion, Cloudflare’s DNS stopped answering some queries.
Per the post-mortem, RRDNS, their in-house DNS software written in Go, measured upstream response times like this:
rtt := time.Now().Sub(start)The leap second stepped time back one second and this rtt went negative.
The value stayed negative through smoothing, reached the random-number function rand.Int63n(), and panicked on the negative argument.
The panic itself was recovered, but the affected DNS lookups failed, touching about 0.2% of queries at peak.
Rolling the fix out everywhere took 6 hours 45 minutes.
Go at the time offered no way to read a monotonic clock, so a time.Now() difference could go negative whenever time stepped back.
Go 1.9 resolved this by having the runtime carry a monotonic clock, one that keeps counting up regardless of wall clock steps and adjustments.
The smearing workaround
The big providers stopped taking the leap second as a step.
Instead of inserting one second at once, they stretch it thin over a long window and let their clocks run slightly slow.
This is leap smearing.
| Implementation | Stretch | Window |
|---|---|---|
| 24 hours | linear, noon to noon UTC | |
| Meta | 17 hours | from 00:00 UTC |
Google has smeared since 2008, and in the 24-hour linear smear the clock runs slow by 11.6 ppm (11.6 parts per million).
Each second gets about 11.6 microseconds longer, adding up to the full second over 24 hours.
AWS uses the same 24-hour smear.
Smearing protects your own systems, but the time you serve drifts off the standard.
A smeared clock sits up to 0.5 seconds away from UTC.
Clocks with different windows also disagree with each other, so Google’s and Meta’s servers would return different times while working through the same leap second.
Meta argued in its 2022 post that further insertions do more harm than good and that the count should stop at 27.
The considerations in Draft Resolution C also point out that providers’ differing workarounds create inconsistency in distributed time.
The negative leap second
All 27 insertions added a second; a removal has never happened.
In a negative leap second, 23:59:58 is followed directly by 00:00:00 the next day.
Earth has been spinning faster these past few years.
A paper that Duncan Agnew of Scripps Institution of Oceanography published in Nature in March 2024 predicted that at this rate, UTC will need a second removed by 2029.
Tracking the melting of Greenland and Antarctic ice by satellite gravimetry, the changing distribution of the meltwater is slowing the rotation.
Removing that effect shows the deceleration of Earth’s core steadily speeding up the rest of the planet.
2029 is the extrapolation of both trends, and without the accelerated melting it would have arrived three years earlier.
According to the considerations in Draft Resolution C, a workshop that CCTF (Consultative Committee for Time and Frequency) and IERS held in March 2025 estimated the probability of a negative leap second rising rapidly, reaching 30% by 2035.
The draft also writes that preparing for one would take investment on the scale of millennium-bug preparations across industries that depend on time synchronization.
The 2029 prediction lands before 2035, the deadline in the 2022 resolution.
Draft Resolution C’s effective date sits earlier still, on May 20, 2027.
Working groups such as ITU-T and IEEE 1588 had sent statements to the BIPM asking to bring continuous UTC forward to avoid the risk of a negative leap second insertion.
Meta wrote that a negative leap second has never been tested at scale and could have a devastating effect on software that relies on timers or schedulers.
The leap seconds on my M4 Mac mini
Test environment
| Item | Detail |
|---|---|
| Machine | M4 Mac mini, macOS 26.5.2 |
| Checked | /usr/share/zoneinfo/leapseconds from tzdata, Python 3.14.4 |
The leap second list still ships with operating systems.
I went looking for where it sits on macOS, and it was part of tzdata.
$ tail -8 /usr/share/zoneinfo/leapseconds
Leap 2015 Jun 30 23:59:60 + S
Leap 2016 Dec 31 23:59:60 + S
(snip)
#updated 1783323897 (2026-07-06 07:44:57 UTC)
#expires 1814140800 (2027-06-28 00:00:00 UTC)The final entry is still New Year’s Eve 2016, while the file itself was updated on July 6, 2026.
That follows Bulletin C 72, dated July 6, 2026, which announced no insertion at the end of December 2026, and the expiry moved out to June 28, 2027.
Nine and a half years without an insertion, and the cycle of confirming the skip and extending the expiry every six months keeps turning.
How this list feeds actual clock synchronization is the NTP daemon’s side of the story, and I did not chase it further.
Meanwhile, some of the everyday time machinery has no slot for a leap second at all.
Asking Python’s datetime for 23:59:60 gets rejected.
>>> datetime(2016, 12, 31, 23, 59, 60)
ValueError: second must be in 0..59, not 60Unix time also counts every day as exactly 86400 seconds.
Subtracting timestamps across the 2017 leap second yields just 1.
2016-12-31T23:59:59Z -> 1483228799
2017-01-01T00:00:00Z -> 1483228800In between, 23:59:60 really happened and 2 seconds elapsed.
What to do with that extra second is left to each implementation, and RFC 7164 lists ticking the same second twice, stopping the clock, and smearing it thin.
The 2012 outage came from the kernel timer at insertion time, and the 2017 outage came from code that assumed time never goes backwards.
Why DST is fine and leap seconds are not
By sheer width, the one-hour shift of daylight saving time or the full day of a leap year dwarfs one second, yet Reddit and Cloudflare went down over the one second.
POSIX systems keep their internal time as Unix time, counted against UTC, and local time is displayed by adding a timezone offset.
Daylight saving time shifts that offset and nothing more, so Unix time ticks straight through the transition without skipping a second.
The shift is an hour in most places, with exceptions like the 30 minutes on Lord Howe Island.
The rules sit in tzdata ahead of time as predictions, and in regions that observe DST the switch actually runs twice a year.
February 29, the day a leap year adds, changes nothing about minutes and seconds either; in Unix time it counts as the same 86400 seconds as any other day.
A leap second goes not into that offset but into UTC itself.
The inserted 23:59:60, as the ValueError and the subtraction above show, has no representation in Unix time.
Assumptions software has leaned on stop holding: time never goes backwards, a minute has 60 seconds, timestamps only grow.
The lead time differs as well.
Future DST rules can be shipped in tzdata ahead of time, while a leap second depends on Earth’s rotation, confirmed only six months out by Bulletin C.
Those six months are the whole preparation window, and then a code path that runs once in several years fires across the whole world at once.
The one-hour switch happens twice a year where DST is observed; the one-second insertion has not happened in nine and a half years.