The General Conference on Weights and Measures voted on October 15 to stop inserting leap seconds into UTC. Resolution 5 of the 28th CGPM, adopted in Versailles, makes UTC continuous from May 20, 2027, and lets it drift up to 3,600 seconds from Earth rotation time before anyone has to act. The 2022 conference had set a deadline of 2035. This vote pulled it in by eight years.

The last leap second went in at the end of December 2016. It was the 27th since 1972. The IERS confirmed in July that there will be none in December 2026, and the new rule takes effect before the June 2027 window opens. So the count stops at 27, and UTC stays 37 seconds behind TAI for the rest of our careers.

The negative leap second nobody has tested

Earth sped up. Since around 2020 the planet has been rotating a little faster than the atomic second assumes, and the gap between UT1 and UTC has been shrinking instead of growing. A workshop run by the CCTF and the IERS in March 2025 put the odds of a negative leap second before 2035 at 30 percent. That number is in the resolution's recitals. Nick Stamatakos, who runs the Earth Orientation Department at the US Naval Observatory, told Scientific American that "avoiding negative leap seconds is a very big driver to open the window."

A negative leap second is a minute with 59 seconds in it. Clocks go from 23:59:58 to 00:00:00. No production system has ever done it. Every NTP daemon and every kernel carries code for the case, and none of that code has run outside a lab. The metrology community looked at that and chose never to find out.

Noël Dimarcq, the CNRS scientist who chairs the CCTF, put it this way in his statement after the vote: "After 30 years of debates, we are ready." The same statement says the one hour limit should keep UTC continuous for several millennia. The drift is under a second a year today. A full minute of divergence takes more than a century to build.

What positive leap seconds cost

The track record of the ordinary kind is bad enough. On June 30, 2012, the Linux kernel's hrtimer subsystem mishandled the inserted second and sent CPUs into a spin on machines running Java and MySQL. Reddit was down for 30 to 40 minutes. LinkedIn and Mozilla went with it, and so did the Amadeus reservation system behind Qantas.

On January 1, 2017, Cloudflare's RRDNS service measured upstream response times by calling Go's time.Now() twice and subtracting. The clock stepped back one second at midnight UTC, the difference went negative, and the smoothed value eventually reached rand.Int63n(), which panics on a negative argument. About 0.2 percent of DNS queries failed at peak, across 102 data centers, until the last fix landed at 06:45 UTC. Cloudflare's own write-up names the root cause as the assumption that time cannot go backwards. Go 1.9 added a monotonic clock reading to time.Time that August.

Meta's production engineering team called for an end to leap seconds in July 2022, citing both incidents. Meta smears its leap seconds over 17 hours with a quadratic curve. Google smears over 24 hours, noon to noon, linearly. Amazon does something close to Google. The resolution lists this inconsistency among its reasons. When the big providers each smear on a different schedule, two correctly configured clocks disagree by up to half a second for most of a day, and anyone comparing timestamps across providers gets garbage.

What changes on your machines

Less than you'd hope, for a while.

  • The leap second list that ships in tzdata, and that chrony and ntpd read, carries an expiry date. Expect it to keep getting republished with no new entries. Software that warns on an expired file will keep warning if a distribution stops shipping updates, so that code path stays live.
  • GPS time stays 18 seconds ahead of UTC. Permanently, as far as this resolution is concerned. Code that hardcodes the offset becomes correct by accident. Code that reads it from the navigation message keeps working.
  • Smear configuration can come out of NTP server fleets after May 2027. Leave the client side alone. A step from a misconfigured upstream looks the same as a leap second to a client, and the handling that protects you from one protects you from the other.
  • Radio time signals such as WWVB and MSF encode the UT1 minus UTC difference in a field that only holds values under a second. ITU-R gave broadcasters until 2035, and 2040 where hardware can't be swapped, to change the format.

The bug class the Cloudflare incident belongs to was never a leap second bug. It is a wall clock bug. Subtracting two wall clock readings to get a duration breaks on an NTP step, on a VM live migration, on an admin fixing a wrong clock by hand, and on a leap second. Three of those four survive this vote. If anyone reads this decision as permission to drop monotonic clocks from their timing code, they have learned the wrong lesson from 2017.

Same goes for the test suites. If you have a fixture that fakes a 23:59:60 timestamp, keep it. Parsers in the wild will keep receiving that string from old logs and old hardware for decades, and a parser that rejects it is still a parser that drops data.

The objection that lost

The case against was that civil time should track the sun. It stopped doing that a long time ago, in any way a person can notice. Time zones already put solar noon anywhere from a few minutes to more than an hour off 12:00, depending on where you stand in the zone, and daylight saving moves it another hour for half the year. A second of drift per year is noise against that. The people who need UT1 (astronomers and geodesists, mostly) already pull it from IERS tables and never used UTC as a proxy for it in anything that mattered.

What the resolution leaves open is the mechanism at 3,600 seconds. It sets the limit and says nothing about how the correction happens. The BIPM is asked to monitor the drift and report to the CIPM, and that is all. A leap hour a thousand years from now is someone else's problem, and the drafters wrote it that way on purpose. The 1972 design assumed the computers of 1972 and held up for 54 years. This design assumes the drift stays slow and a future committee can be trusted with the rest. I'd take that bet.

Which means 23:59:60 UTC on December 31, 2016 was the last time a correct clock displayed that value. If you still have the incident reports from that night, they are now history documents. File them accordingly.