The Decision
The bodies that set global time standards have decided to stop adding leap seconds. The move aims to prevent leap seconds from turning into a widespread coordination failure similar to the Y2K problem. The primary stated reason is the difficulty of updating large fleets of IoT devices that lack easy mechanisms for time adjustments.
This policy treats the installed base of connected hardware as fixed. No further insertions will occur under current rules. The change removes an ongoing source of operational friction for anyone running systems that must stay synchronized across many endpoints.
Context
Leap seconds have been inserted irregularly since 1972 to keep atomic time aligned with Earth’s rotation. Until now, each insertion required coordinated updates across software, networks, and hardware. The new policy removes that requirement going forward. The decision treats the existing stock of connected devices as effectively unpatchable at scale.
Operators have long managed the occasional extra second through software patches, configuration changes, and scheduled downtime windows. Those steps worked when most time-sensitive systems sat in data centers or on managed servers. The growth of embedded devices changed the equation. Many IoT units ship with time logic baked into firmware that never receives updates after deployment.
Details
The cited obstacle is the sheer number and diversity of IoT endpoints that embed time logic in firmware. Many of these devices operate for years without updates and have no provision for handling an extra second. Without a uniform way to propagate the change, operators face the choice of either accepting accumulating drift or risking crashes during the next insertion. The policy change therefore freezes the current offset between UTC and TAI.
No schedule for resuming leap seconds was announced. The bodies framed the step as permanent until a different technical solution emerges. The Register reporting notes that the IoT constraint outweighed other concerns in the final vote.
The practical barrier is not theoretical. Devices that run for a decade on a single firmware image cannot be reached for a one-time adjustment. Even when network connectivity exists, many lack the ability to accept a new time offset without a full reflashing process. That process often requires physical access or vendor cooperation that no longer exists for older product lines. The standards bodies concluded that repeating this coordination problem every few years created unacceptable risk.
Why it matters
Software engineers who maintain distributed systems now have one fewer variable to track. Code paths that previously had to accommodate occasional 61-second minutes can be simplified or removed. At the same time, the decision shifts the burden onto long-term device manufacturers: any future misalignment between atomic time and solar time will have to be absorbed by applications rather than by the clock itself.
For fleets that already struggle with firmware updates, the change reduces immediate operational risk but locks in a growing divergence that may surface in other forms, such as scheduling drift in astronomy or satellite systems. The practical effect is that timekeeping code becomes simpler while the underlying physical mismatch persists.
Over longer horizons the accumulated difference between atomic time and solar time will reach several seconds. Systems that rely on precise alignment with daylight or astronomical events will need to handle that offset in application logic rather than at the operating-system level. Manufacturers of new hardware can design around a fixed offset, but the existing device population cannot. This creates a permanent split between devices built before the policy change and those built after it.
The move also removes a recurring test case that forced teams to verify leap-second handling in their monitoring and alerting stacks. That verification work will no longer be necessary, freeing engineering hours for other reliability tasks. The trade-off is that any future correction mechanism will have to solve the IoT update problem first, or the standards bodies will face the same impasse again.
---
Sources:
No comments yet