In October the General Conference on Weights and Measures votes on a resolution that makes UTC continuous from 20 May 2027. If it passes — and everything suggests it will — there will be no more leap seconds for a very long time. The trade-off: the difference between UTC and UT1, the scale that tracks the planet's actual rotation, will be allowed to grow to as much as one hour.
What is actually being voted on
Today UTC is driven by atomic clocks, and the leap second exists to keep it within 0.9 seconds of the time dictated by the Earth's spin, which does as it pleases. Since the system started in 1972, 27 leap seconds have been added.
The urgency comes from the Earth's rotation having sped up slightly in recent years. That opens the door to something never attempted: removing a second instead of adding one. A group of experts convened by the international timekeeping bodies put the probability of needing a negative leap second before 2035 at 30 per cent.
Setnam Shemar, principal scientist at the UK's NPL, puts it plainly: almost every digital architecture and network time server out there is written on the assumption that seconds are only ever added.
"Losing a second could trigger severe disruption across critical national infrastructure" — telecoms, electricity grids and satellite navigation included.
Hence the proposal to widen the margin to an hour and be done with it. Shemar expects the resolution to pass, because most national delegations have wanted this closed for years, and he reckons the gap would not reach a full hour for at least a thousand years. If we are still around to see it, we will have other worries.
Why this matters if you build or maintain software
The bug was never the second. It was the subtraction
Positive leap seconds have already knocked things over. In the first second of 2017, Cloudflare reported that part of its DNS went down because a duration calculation came out negative: one instant was "earlier" than another that came before it, and the code had no case for that. The leap second broke nothing by itself; it broke the assumption that time moves forward and subtractions come out positive.
A negative second is worse for one very concrete reason: nobody has ever run that code path in production. Fifty years, zero field testing. When you read the leap-indicator handling in a time daemon, the "subtract" branch is, at best, well-written theory.
Having that possibility taken off the calendar is the best infrastructure news of the year, and almost nobody will celebrate it, because the failure it prevents is invisible.
What I would do differently from today
You do not need to wait until 2027 to get something out of this. A short review, in order of payoff:
- Measure durations with a monotonic clock, not wall-clock time.
CLOCK_MONOTONIC,System.nanoTime(),time.Sincein Go. If you are subtracting two timestamps to find out how long something took, the leap second is the least of your problems: an NTP correction or a suspended virtual machine will break it just the same. - Assume a duration can come out negative and decide what to do: treat it as zero, log it, retry. What you cannot do is divide by it.
- Grep for hardcoded 86400. Any calculation that turns days into seconds by multiplying is a review candidate, and not only because of this: daylight saving already gives you days of 23 and 25 hours.
- Look at how your time is really set up. Which NTP clients, against which servers, whether anyone is smearing (spreading the second over hours), and whether your cloud providers and your own machines do the same thing. Mixing two leap-second strategies in one cluster is the silliest way to end up with nodes whose clocks disagree.
- Check the alerts that depend on the leap-second table. Those files carry an expiry date and some daemons complain when it passes. From 2027 the table stops changing for good; make sure your monitoring does not read that as "stale time data" and start paging for nothing.
- If you use TAI-based time zones (tzdata's
right/set) or store instants in atomic scales, note that they stop growing. Nothing breaks, but the assumption changes.
What you genuinely lose: UTC stops being a sundial
Here is the small print that rarely gets told. Until now you could treat UTC as an approximation of the Earth's rotation angle with under a second of error. From May 2027 that stops being true by design: the gap will grow, slowly but without going back.
Anyone pointing antennas, driving telescopes, processing ephemerides or doing geodesy now has to separate two things many systems conflate: civil time (UTC) and Earth orientation (UT1). And if you receive the DUT1 value in some time-broadcast format with a field designed for sub-second values, that field will run out of room at some point. Not urgent, but exactly the sort of thing worth looking at while the system can still be touched without pressure.
What does not change
- Nothing is official yet. The vote is in October and the start date is May 2027. Until then the current mechanism still stands on paper, even though no leap second has been added since the end of 2016.
- The problem is not removed, it is postponed. The tolerance goes from 0.9 seconds to one hour. That is a postponement measured in centuries, which in engineering is as good as forever, but the resolution says nothing about what happens when the limit is reached. Someone else's headache.
- Your clock is still your responsibility. Ninety-nine per cent of the time bugs I have run into had nothing to do with leap seconds: they came from misconfigured NTP, containers inheriting odd clocks, dates stored without a time zone, and subtracting
datetimevalues with the best of intentions. - UTC stays atomic. What is being adjusted is the rule that ties it to the Earth's rotation, not the definition of the second.
If you run systems where time is critical — interval billing, queues ordered by timestamp, synchronisation between nodes — this is a good moment for that review, precisely because nothing is on fire. Any questions, tell me and we will go through it.
Best, Vicente.