Global timekeepers have pulled the plug on one of the oddest quirks in modern computing. On October 19, 2026, The Register reported that the General Conference on Weights and Measures, known by its French acronym CGPM, voted at its 28th meeting to end the practice of inserting leap seconds into Coordinated Universal Time. The decision closes out more than five decades of manual clock patching and opens a new, messier problem for the engineers who actually have to update the code.
For most people, a leap second is an invisible non-event. For software engineers who maintain time-sensitive systems, it has long been a dreaded calendar entry, the kind of change that quietly breaks schedulers, replication logs and financial trading systems. Now that leap seconds are being retired in favor of a scheme called “Continuous UTC,” the question facing developers isn’t whether time sync changes, but how much legacy code silently assumes the old rules still apply.
Don't miss new tech stories on Google
Add Tech Insider once in the Google app and our stories appear in your news suggestions.
What the CGPM Actually Voted to Change
The CGPM’s resolution, as cited in reporting on the vote, lays out a specific and somewhat unusual justification. A negative leap second, one that would subtract a second from UTC rather than add one, has never actually been applied in the history of timekeeping. The resolution states plainly that this untested maneuver “has not previously been applied, and it is considered to pose a high risk of causing anomalies and disruption to critical infrastructures that are largely unprepared.” That’s a notable admission from a standards body: the fix for a drifting clock was judged riskier than the drift itself.
The resolution goes further, drawing an explicit comparison that will sound familiar to anyone who worked in IT before the year 2000. Preparing systems for a negative leap second, the CGPM noted, would require financial investment from every industry that depends on synchronized time, investment the resolution describes as comparable in scale to the preparations made for the millennium bug. That comparison is doing a lot of work here: it reframes leap seconds from a quirky astronomical footnote into a genuine line item on corporate risk registers.
Reporting on the decision, picked up by outlets including Межа, frames the vote as timekeepers moving preemptively rather than reactively. Instead of waiting for a negative leap second to actually cause an outage and then scrambling to patch it, the CGPM chose to remove the entire mechanism first.
Why a Second That’s Never Happened Was So Risky
To understand why a hypothetical negative leap second worried standards bodies enough to abolish the whole system, it helps to understand what leap seconds were compensating for in the first place. Earth’s rotation is not perfectly stable. It generally runs very slightly slower than the atomic clocks that define UTC, which is why, since 1972, timekeepers have periodically inserted a positive leap second to let the planet “catch up” to the clock. Every insertion has added a second. None has ever subtracted one.
That one-directional history matters because software that handles time rarely gets tested against the direction it has never seen. Code paths, date libraries, and embedded firmware that assume a minute can only ever contain 59, 60, or that a day can only ever run long, have had decades to quietly bake that assumption into system behavior. A negative leap second would require a clock to skip from 23:59:58 straight to 00:00:00, erasing a second that every downstream system expects to exist. According to the reporting on the CGPM’s resolution, it’s precisely that untested edge case, paired with the proliferation of connected devices, multi-sensor systems, smart grids, and virtual services that all depend on precise synchronization, that pushed the vote toward elimination rather than preparation.
Meta’s production engineering team made a similar argument years before this vote, when the company publicly lobbied against continuing the practice. As Meta engineers Oleg Obleukhov and Ahmad Byagowi put it in a 2022 engineering blog post, “Leap second events have caused issues across the industry and continue to present many risks. As an industry, we bump into problems whenever a leap second is introduced. And because it’s such a rare event, it devastates the community every time it happens. With a growing demand for clock precision across all industries, the leap second is now causing more damage than good, resulting in disturbances and outages.” The CGPM’s 2026 vote effectively ratifies that argument at the standards-body level.
Inside “Continuous UTC”: How the Replacement Actually Works
The mechanism replacing leap seconds is being referred to in coverage of the vote as “Continuous UTC.” Rather than periodically forcing UTC back into lockstep with UT1 (the astronomical time scale tied to Earth’s actual rotation), the new scheme lets the two diverge. Per the reporting, Continuous UTC permits UT1 and UTC to drift apart by up to 3,600 seconds, a full hour, before any correction is even considered.
That’s a dramatic widening of tolerance. Leap seconds kept the two time scales within roughly a second of each other at all times. A 3,600-second allowance effectively tells the world’s computers to stop worrying about sub-minute astronomical drift entirely, and to treat UTC as what it was arguably always meant to be for computing purposes: a clean, monotonically increasing count, free of the occasional 61-second minute that has broken schedulers, logging pipelines and real-time systems for decades.
The timing detail is important for anyone planning technical work around this: coverage of the decision indicates the Continuous UTC scheme is set to come into force next year, relative to the October 2026 reporting date, meaning engineering teams have a comparatively short runway to audit systems before the new rules are live.
The Code That Actually Breaks When Time-Sync Rules Change
This is where the story stops being an abstract standards debate and becomes a genuine coding-tools problem. Time handling is one of the most quietly fragile layers in any software stack, and it touches nearly every part of the modern toolchain: ORMs that serialize timestamps, database engines that store time-zone-aware columns, language runtimes with their own internal clock representations, and distributed systems that rely on synchronized clocks for ordering events.
Consider the layers where a leap-second assumption can hide. NTP (Network Time Protocol) daemons carry a dedicated “leap indicator” field specifically so clients know a leap second is coming. Database engines like the one behind PostgreSQL store timestamp types that assume consistent second-counting. Language runtimes and frameworks, from the date libraries shipped with Java to the time-handling utilities bundled with .NET, often bake POSIX time assumptions deep into their standard libraries. ORMs such as those compared in a recent look at SQLAlchemy, Django ORM and SQLModel pass timestamps through multiple serialization layers, any one of which can mishandle an unexpected second.
None of this is hypothetical paranoia. It’s the exact pattern that caused real, documented incidents the last time a leap second was inserted: Java’s thread-scheduling code, Linux kernel timers, and various database replication systems have all had well-publicized leap-second-related failures in past insertions. The CGPM’s resolution explicitly calls out “connected devices, multi-sensor systems, smart grids, and virtual services” as categories of infrastructure that are largely unprepared for a disruptive time-sync event. That list reads like a checklist for anyone running production infrastructure in 2026.
// Pseudocode: a leap-second-aware check that becomes obsolete under Continuous UTC
function isLeapSecondPending(ntpLeapIndicatorBits) {
// LI = 1 means last minute of the day has 61 seconds
// LI = 2 means last minute of the day has 59 seconds
// Under Continuous UTC, this field is expected to stop signaling future events
return ntpLeapIndicatorBits === 1 || ntpLeapIndicatorBits === 2;
}That pattern, checking an NTP leap indicator bit before every day boundary, exists today across countless time-sync libraries. Under Continuous UTC, the field doesn’t disappear overnight, but the events it signals are expected to stop occurring, which means dormant code paths that haven’t been exercised in years may now go permanently untested, a different but related risk to the one the CGPM is trying to eliminate.
Market Impact: Who Actually Pays for This Transition
The CGPM’s own resolution draws the Y2K comparison, and it’s worth taking seriously as a market signal rather than just a headline hook. The millennium bug prompted an enormous wave of IT spending in the late 1990s, as companies audited, tested and patched date-handling code across mainframes, embedded systems and enterprise software. The resolution’s language, that preparing for a negative leap second would require financial investment “estimated to be similar to preparations for the millennium bug,” suggests standards bodies expect a comparable audit cycle, just compressed into a shorter and less publicly dramatized window.
Where that spending lands first is predictable: cloud infrastructure providers, database vendors, and enterprise software teams responsible for time-sensitive systems like billing, logging, and transaction ordering. Security and patch-management teams are also likely to feel this. Patch Tuesday cycles already ship fixes touching time-handling code regularly; a transition to Continuous UTC gives vendors a concrete new category of time-sync patches to track and prioritize over the coming year.
There’s also a quieter winner in this shift: teams that already adopted smear-based time handling, rather than hard leap-second insertion, are far better positioned. That approach, pioneered publicly by Google, spreads the time adjustment gradually across a window rather than forcing a discrete jump. Google engineer Christopher Pascoe described the company’s own fix for this exact problem years ago: “The solution we came up with came to be known as the ‘leap smear.'” Google principal engineer Peter Hochschild explained the mechanics in plainer terms: “What we would have the computers do is very slowly smear out that one second, leap second, rather than do it all of a sudden.” Systems built around smearing already treat time as continuous and elastic, which is conceptually close to what Continuous UTC formalizes at the standards level.
Historical Context: Five Decades of Patching the Clock
Leap seconds have been part of UTC since 1972, when the system was adopted specifically to reconcile atomic-clock precision with Earth’s gradually slowing rotation. For more than fifty years, the mechanism worked by periodic, manually scheduled insertions, announced in advance by international timekeeping bodies and applied uniformly across global systems. It was a workable patch for a pre-internet, pre-cloud-computing world, where the number of systems that needed to agree on the exact second was comparatively small.
That calculus has changed enormously. The scale of distributed, time-synchronized infrastructure in 2026, spanning cloud regions, financial exchanges, telecom networks, and billions of connected devices, is orders of magnitude larger than it was even twenty years ago. Each leap-second insertion over the past decade has drawn public reporting of software hiccups tied to the adjustment, reinforcing the view among engineering teams at companies like Meta and Google that the insertion mechanism itself had become more dangerous than the astronomical drift it was designed to fix. The CGPM’s 2026 vote is, in that sense, the standards world catching up to an argument the software industry had already been making for years.
Competitive Comparison: How Different Time-Sync Approaches Stack Up
With Continuous UTC incoming, engineering teams effectively have three philosophies to choose from when it comes to handling the transition inside their own systems: continue relying on standard NTP leap-indicator signaling (soon to go largely unused), adopt a smear-based approach similar to Google’s, or move toward hardware-based time sources like GPS and Precision Time Protocol (PTP) that sidestep leap-second logic in dedicated appliances. Each has tradeoffs in complexity, cost, and how much legacy code needs to change.
| Approach | How It Handles Time Jumps | Code Changes Needed | Best Fit |
|---|---|---|---|
| Standard NTP leap indicator | Discrete second insertion/removal signaled via LI bits | High, assumes future leap events keep occurring | Legacy on-prem systems |
| Leap smear (Google-style) | Gradual adjustment spread across a window | Moderate, requires smear-aware clock libraries | Large distributed cloud fleets |
| GPS / PTP hardware time | Independent of UTC leap-second mechanism | Low for new deployments, high for retrofits | Financial trading, telecom |
| Continuous UTC (new standard) | Allows up to 3,600s UT1/UTC drift, no insertion events | Required across all time-sync libraries | All systems, post-transition |
What stands out in that comparison is that Continuous UTC doesn’t just add a fourth option, it’s designed to eventually make the leap-indicator approach obsolete across the board. That’s a meaningful shift for any team still running infrastructure that leans on the oldest signaling method, since the assumption that leap events will keep arriving on a predictable schedule no longer holds.
A Developer Checklist for the Transition Window
Given the comparatively short runway before Continuous UTC takes effect, engineering teams have a practical, bounded set of things worth auditing now rather than waiting for a specific deadline to force the issue.
- Inventory every service that reads or reacts to the NTP leap indicator field, including monitoring and alerting systems built around it.
- Check database and ORM layers, including setups built on SQLAlchemy, Django ORM or SQLModel, for any code that explicitly branches on a 60- or 61-second minute.
- Review language runtime date libraries for hardcoded leap-second tables that will need periodic updates under the new drift-tolerant model.
- Confirm logging and event-ordering systems don’t assume strict second-level monotonicity without accounting for the wider UT1/UTC divergence window.
- Track vendor patch notes closely, since fixes tied to this transition are likely to surface inside routine security and maintenance updates rather than as a single flagged release.
Expert and Engineering Voices on the Shift
The case against leap seconds has been building inside the engineering community for years, well before the CGPM’s 2026 vote made it official policy. Meta’s production engineering team argued publicly that the risk calculus had tipped decisively against the old mechanism, writing that “introducing new leap seconds is a risky practice which does more harm than good, and we believe it is time to introduce new technologies to replace it.” That position, laid out by Meta’s Oleg Obleukhov and Ahmad Byagowi, closely anticipates the logic the CGPM ultimately adopted.
Google’s own engineering history offers a preview of what large-scale adaptation to this kind of change actually looks like in practice. Years before the CGPM vote, Google built its leap-smear system specifically to avoid forcing a discrete time jump across its fleet. As Christopher Pascoe described it, the company needed a way to avoid “the solution we came up with came to be known as the ‘leap smear,'” and Peter Hochschild’s description of the technique, slowly smearing out the adjustment “rather than do it all of a sudden,” reads today like a design pattern the rest of the industry is now being pushed toward by the standards change itself.
A Timeline of Global Timekeeping Milestones
| Period | Milestone | Relevance to Software Teams |
|---|---|---|
| 1972 | UTC adopts leap seconds to track Earth’s rotation | Introduces the discrete second-insertion model still used today |
| 2012 and later insertions | Periodic leap-second events draw public reports of software issues | Pushes major platforms toward smear-based alternatives |
| 2022 | Meta publicly argues for ending leap seconds | Signals industry consensus ahead of formal standards action |
| October 2026 | CGPM votes at its 28th meeting to abolish leap seconds | Formal start of the transition window for engineering teams |
| Next year (per reporting) | Continuous UTC scheme takes effect | Deadline for auditing legacy leap-second-dependent code |
Predictions: What Happens Next
- Expect cloud providers and major database vendors to publish dedicated migration guidance for Continuous UTC well before the scheme takes effect, mirroring the advisory wave seen ahead of Y2K.
- Security patch cycles, including upcoming Patch Tuesday releases, are likely to start folding in time-sync-related fixes as vendors audit leap-indicator-dependent code.
- Smear-based time handling, already used internally at companies like Google, is likely to see broader external adoption as teams look for a lower-risk path through the transition.
- Legacy on-prem systems and embedded devices, the categories explicitly flagged in the CGPM’s resolution, will likely be the slowest to adapt and the most likely source of any disruption once Continuous UTC is live.
- Expect renewed scrutiny of NTP and PTP implementation libraries across open-source ecosystems, as maintainers work out how much of the existing leap-second logic can simply be deprecated versus rewritten.
Why This Matters Beyond the Standards World
It’s tempting to file this under obscure metrology news, but the CGPM’s vote lands squarely in territory that affects working developers. Time handling bugs are notoriously hard to catch in testing precisely because the triggering conditions are rare and calendar-dependent, the same property that made the old leap-second mechanism risky in the first place. A standards body choosing to eliminate an entire class of rare-but-catastrophic edge cases, rather than asking every downstream system to individually harden itself against one, is a meaningfully different approach to risk management than most software teams are used to seeing from an external body.
Further reading on the science behind the decision is available from outlets that have covered the story’s physics angle, including IFLScience’s coverage of the timekeepers’ decision and analysis from Brookings on the broader policy implications. Technical background on how leap seconds have historically been implemented is also maintained by nwtime.org’s leap second resources page.
What Teams Running Time-Sensitive Infrastructure Should Watch
For teams maintaining databases, distributed systems, or anything that depends on precise event ordering, the practical advice emerging from this story is less about panic and more about inventory. The CGPM’s resolution gives a concrete category of infrastructure to check: anything connected, anything running multiple sensors in sync, smart grid components, and virtual services that assume strict second-level timing. Tools already common in security and compliance workflows can be extended to flag outdated time-sync library versions as part of a broader audit, even though they weren’t built specifically for this purpose.
Framework maintainers are also a piece of this puzzle. Full-stack frameworks such as TanStack Start, which handle server-side rendering and often touch request timestamps directly, will need to confirm their time-handling dependencies don’t carry stale leap-second assumptions baked in from upstream libraries.
Frequently Asked Questions
What did the CGPM actually vote to do?
At its 28th meeting, the General Conference on Weights and Measures voted to end the use of leap seconds, replacing the old insertion mechanism with a new scheme described in reporting as “Continuous UTC.”
Why did timekeepers decide to abolish leap seconds now?
The CGPM’s resolution states that a negative leap second has never been applied and is considered high risk for causing anomalies and disruption to critical infrastructure that is largely unprepared for it.
What is Continuous UTC?
It’s the replacement scheme described in coverage of the vote, which allows UT1 and UTC to diverge by up to 3,600 seconds rather than forcing periodic one-second corrections.
When does the new scheme take effect?
According to reporting on the decision, the Continuous UTC scheme is set to come into force next year, relative to the October 2026 announcement.
Is this really comparable to the Y2K bug?
The CGPM’s own resolution draws that comparison, noting that preparing industries for a negative leap second would require financial investment estimated to be similar in scale to millennium bug preparations. That’s the standards body’s framing, not an independent estimate.
What kinds of systems are most at risk?
The resolution specifically names connected devices, multi-sensor systems, smart grids, and virtual services as categories largely unprepared for disruption tied to this kind of time-sync change.
Did any companies push for this change before the CGPM vote?
Yes. Meta’s production engineering team publicly argued against continuing leap-second insertions years earlier, and Google built its own “leap smear” system to handle time adjustments gradually rather than through a discrete jump.
What should developers do right now?
Start by inventorying any code that reads NTP leap-indicator signals, checking database and ORM timestamp handling, and watching vendor patch notes for time-sync-related fixes as the Continuous UTC deadline approaches.
