The world's timekeepers want to avoid making software handle its first 59-second minute. The General Conference on Weights and Measures has decided that UTC will become continuous on 20 May 2027, ending leap-second adjustments to avoid a first negative leap second.
For developers, the useful distinction is between removing an adjustment from the world's reference time and making an application's clock safe to measure durations. Those are separate jobs. Python's clock documentation makes the distinction explicit: its monotonic clock is unaffected by system clock updates, and only differences between readings have meaning. Continuous UTC won't make that API unnecessary.
Why a missing second worries operators
Leap seconds connect two measurements that don't keep precisely the same pace. Atomic clocks provide a stable measure of time. UT1 follows Earth's irregular rotation. As NIST explains, Earth sometimes speeds up and sometimes slows down, although its rotation slows over longer intervals. Corrections have kept UTC within 0.9 seconds of astronomical time.
Every leap second used so far has added time. A clock can represent that extra second as 23:59:60, between 23:59:59 and midnight. A negative leap second would instead move from 23:59:58 directly to 00:00:00. NIST's examples show the difference plainly: a timestamp that would normally exist disappears. Software prepared for the extra second hasn't necessarily been exercised against the missing one.
The 2026 resolution cites a workshop estimate that the probability of needing a negative leap second reaches 30% by 2035. It describes critical infrastructure as largely unprepared. It hasn't announced a date for such a deletion.
The earlier decision left time to settle the details
In 2022, the conference agreed to increase the permitted difference between UTC and UT1 in or before 2035. It asked for a limit that would keep UTC continuous for at least a century, together with an implementation plan. The concern already extended beyond individual clock jumps: network and satellite operators had developed different ways of handling them, leaving synchronization dependent on which method a system used.
The new resolution sets the permitted difference at 3,600 seconds, or one hour. That limit is intended to preserve continuity for several centuries. It doesn't schedule an hour-long clock change in 2027. The immediate change is permission for atomic time and Earth-rotation time to drift further apart.
UTC will still depend on an international measurement system. The BIPM describes its production as a calculation using contributions from around 80 time laboratories and approximately 450 atomic clocks. Laboratories maintain local realizations, called UTC(k), and compare them with the international reference. Ending leap adjustments doesn't remove the need to measure clock differences or distribute accurate time to users.
A DNS failure shows where the trouble can surface
Cloudflare's postmortem from 1 January 2017 describes a failure several steps removed from displaying the time. Its DNS software measured how quickly upstream resolvers answered. During the leap-second event, clock behavior produced negative duration measurements. Smoothing those measurements eventually gave the resolver-selection algorithm a negative value, which caused a Go random-number function to panic. At the peak, Cloudflare said approximately 0.2% of its DNS queries were affected. The problem involved CNAME lookups and a small number of machines, rather than every DNS request. Its account of the fix shows why a rare time event can require more than a calendar-library patch: an invalid duration had travelled into code responsible for choosing a server. Engineers stopped negative measurements entering that selection logic.
That incident involved an added leap second. It illustrates the consequences of assumptions about clocks, without proving how a negative leap would behave. In its 2022 argument for ending leap seconds, Meta separately warned that the negative version had never been tested at large scale. Its engineers identified software timers and schedulers as exposed areas. The date on that warning matters: infrastructure operators were raising this concern years before the current decision.
Smearing keeps clocks moving, with different rules
Google's documented workaround spreads an adjustment over 24 hours, from noon to noon UTC. During a positive leap smear, the clock runs slightly slower. It temporarily differs from unsmeared UTC by almost half a second, then agrees again after the adjustment. Google says it has used smearing internally since 2008, although its earlier implementations used different intervals.
Meta described another approach in its 2022 engineering account: a 17-hour smear with a different mathematical curve. These are dated descriptions of operating practices, not commitments about how either company will implement the 2027 transition. They explain why avoiding an abrupt jump on each machine hasn't, by itself, given all machines identical time.
Google's Public NTP FAQ explicitly advises against mixing smeared and unsmeared time servers because results during a leap second may be unpredictable. For a service spanning providers, that makes the upstream time policy part of the application's operating assumptions. An operator checking synchronization needs to know what the sources do around an adjustment, as well as whether the machines can reach them.
Keep the distinction between timestamps and durations
A practical code review can begin with elapsed-time calculations. Python documents time.monotonic() as a clock that cannot go backwards, with an undefined reference point. Subtracting two readings measures an interval. A reading alone doesn't provide a civil timestamp to put in a shared log. Developers need both kinds of information, and the function's documented behavior gives them a reason to choose deliberately rather than reuse one clock everywhere.
Old timestamps also keep their old meanings. RFC 3339 permits a seconds field of 60 when a positive leap second occurs, and specifies 58 as the maximum for a minute with a negative leap. It includes 1990-12-31T23:59:60Z as a historical example. Ending future adjustments gives no reason to discard valid records like that when importing an archive or checking a timestamp parser. The standard also places a leap second at the same instant worldwide. Operating in another time zone doesn't avoid the event.
For teams reviewing a time-dependent system, those sources suggest two separate checks: whether duration measurements use an appropriate clock, and whether stored timestamps preserve the format and meaning of the original data. That's an engineering inference from the clock API and timestamp standard, rather than a migration procedure issued by the conference. Neither check depends on predicting Earth's next change in rotation.
Astronomical software still needs Earth-rotation data
The measurement being allowed to drift remains available to applications that need it. The IERS time-scales service accepts a date and a requested parameter, including the difference between UT1 and UTC. It can return results as JSON or XML. That gives astronomical software an explicit source for the correction instead of relying on UTC remaining within a second of Earth-rotation time. For those applications, the work is to identify where UTC has been treated as a close substitute for UT1. NIST's explanation of the trade-off specifically notes that astronomical equipment and software may need adjustments if UTC stops being corrected. The operational burden moves toward systems that need the rotation measurement, while ordinary synchronized services can avoid repeated leap events.
Watch the implementation guidance from time services and equipment vendors before the May deadline. The resolution asks BIPM to coordinate with affected organizations and support application of the decision. The useful evidence next will be how providers carry that common date through to the clocks their customers actually use.