The post is a plain-text Bulletin C notice from IERS, the international body that decides whether UTC needs a leap second to stay aligned with Earth rotation. This one says no leap second will be inserted at the end of December 2026, so the current UTC minus TAI offset stays at minus 37 seconds. For anyone who does not live in timekeeping land, leap seconds are occasional one-second adjustments to civil time because Earth is not a stable clock. Its rotation shifts with weather, oceans, ice melt, earthquakes, movement in the core, and even large-scale human water redistribution. That is why these adjustments are irregular and only announced months ahead.
The useful center of gravity was not the bulletin itself. It was that leap seconds are a design compromise most software people now view as a bad one. UTC tries to be both an atomic clock and a proxy for mean solar time, and that mix leaks everywhere. Unix timestamps ignore leap seconds. Distributed systems often smear them over hours to avoid a one-second step. That keeps ordering intact, but it means different systems can disagree about what a second even is during the smear window. Several comments landed on the same conclusion from different angles: elapsed time for computers and civil time for humans should be treated as separate products, not forced through one timestamp abstraction.
A second theme was that the world has already decided to wind this down. Commenters pointed to the 2035 cutoff for leap seconds and explained the awkward legal fiction likely to replace them. UTC is defined by international agreement to track solar time, so "just stop" is not the official story. The practical answer is to stop doing leap seconds and let the drift accumulate, perhaps with a far-future "leap hour" that no one alive will ever see. The interesting implication is that the standards world has effectively admitted the operational pain is worse than the value of keeping UTC within one second of mean solar time.
If your systems touch timestamps, distributed ordering, logs, or clock sync, keep treating leap seconds as a real edge case until the 2035 phaseout is actually implemented. Longer term, expect more pressure to separate "elapsed machine time" from "civil solar time" instead of pretending one clock can cleanly serve both.
Mostly amused but strongly anti-leap-second in practical engineering terms. People enjoyed the absurdity of an agency that manages Earth rotation, then quickly converged on the view that leap seconds are a messy standards artifact that break assumptions in software, especially distributed systems and timestamp handling.
Key insights
01
Earth rotation is noisy, not drifting smoothly
Earth’s day length does not just slow down in a clean line. It moves around because the atmosphere, oceans, liquid core, glaciers, earthquakes, reservoirs, and groundwater all shift mass and angular momentum. That makes leap-second scheduling fundamentally measurement-driven, not something you can precompute years out and forget.
Do not build time-sensitive systems on the assumption that Earth-orientation corrections follow a neat calendar rule. If your product depends on precise UTC alignment, ingest authoritative updates rather than baking in expectations.
Unix timestamps do not represent leap seconds directly, so they are already a convenience layer rather than a faithful map of physical seconds. Smearing makes the situation murkier because operators stretch the correction across a window, which preserves monotonic behavior for many workloads but destroys cross-system assumptions about exact elapsed time. The sharp point here is that developers often think they have one universal clock when in practice they have several incompatible approximations.
Audit where your code needs monotonic elapsed time versus wall-clock timestamps. Use separate clock sources and document them, especially if you operate across clouds or vendors with different leap-smear behavior.
Distributed databases pay for this abstraction leak
Systems like Spanner can survive leap seconds, but only by adding machinery such as clock smearing and bounded uncertainty. That is not a free feature. It is extra protocol and operational complexity caused by civil time carrying astronomical baggage that most machine coordination does not need.
If you design ordering or consensus systems, keep civil time out of the critical path wherever possible. Prefer monotonic clocks plus explicit uncertainty budgets over assuming UTC is simple.
The standards path is ending leap seconds without saying so
The likely outcome is not a clean repeal of solar alignment requirements. It is a standards workaround where UTC stops getting leap seconds after 2035 and any catch-up happens as a far-future "leap hour" that is effectively fictional for current systems. That framing matters because it means the ecosystem is not waiting for better engineering. It is using legal language to ratify what operators already want.
Plan for a long transition, not a one-day switch. Vendor time APIs, satellite systems, and legacy software will carry old assumptions well past 2035 even if civil standards move on.
Satellite time systems do not all share UTC’s baggage
One commenter explained that GPS time avoids leap seconds while GLONASS messages are tied more directly to UTC behavior. That split is why a policy change is not just a software toggle. Different navigation systems embedded time assumptions decades ago, and those choices now constrain how quickly the standards world can simplify civil time.
If you consume GNSS feeds, check which timescale each source actually uses and where leap-second conversion happens. Hidden assumptions at that interface can leak into logging, synchronization, and sensor fusion.
The pushback here is that servers already cope with clock jumps, drift, VM pauses, and NTP corrections, so singling out leap seconds as an existential engineering problem overstates the case. From this view, software that fails on a leap second was brittle to begin with. The stronger objection is not technical possibility but whether tracking solar time is worth the complexity at all.
Do not use the coming phaseout as an excuse to leave time handling sloppy. Your systems still need to survive skew, rollback, drift, and resync events even if leap seconds eventually disappear.
Several replies rejected the idea that leap seconds should be pushed down into time zones or local presentation logic. The argument is straightforward. This correction is global, irregular, and tied to Earth rotation itself, so keeping it in UTC avoids a much uglier world where regions might diverge by odd one-second offsets and timezone math gets even worse.
If you propose redesigns, optimize for interoperability before elegance. A theoretically cleaner abstraction can still be the wrong operational choice if it explodes timezone complexity for everyone else.
Global Navigation Satellite System, the Russian satellite navigation system with timekeeping choices that interact differently with UTC and leap seconds.
datacenter.iers.org