The leap second will end in 2035, but it will not go quietly. Between now and the International Telecommunication Union's abolition deadline, Earth may still need one or two more adjustments—possibly even a negative leap second, with an estimated 30% risk before the cutoff. Systems that assumed the leap second was a solved problem are about to discover that its final years are the most treacherous.
At the heart of the problem sits a hack upon a hack. POSIX time_t and the Linux kernel have no native representation for leap seconds. The abstraction assumes exactly 86,400 identical seconds per day, full stop. When reality diverges—as it has 27 times since 1972, and may once or twice more—systems must choose between two incompatible lies.
Stepping inserts the extra second (or removes it) as an instantaneous ±1s jump. This preserves the integrity of the SI second during normal operation, but at the cost of discontinuity: clocks run backward, timestamps duplicate, and cron jobs fire twice at 23:59:60. Smearing stretches or compresses second length over a window—24 hours in Google's widely-deployed implementation, or as long as 18 months in some proposals—keeping timestamps monotonic but redefining the fundamental unit of time during the smear period.
Both approaches are workarounds around a time_t abstraction that cannot express either strategy natively. The tension between them has been an operational problem for years. What is new is that the IETF has stopped pretending the tension can be resolved.
NTPv5 (draft-ietf-ntp-ntpv5-09) introduces a formal "Leap-smeared UTC" timescale flag, alongside UTC, TAI, and UT1. Servers that smear must now advertise it; clients must know which semantics they are receiving. This is the first IETF-level acknowledgment that smeared time and stepped time are different timescales, not merely different implementation tactics. The protocol now labels the schism rather than attempting to bridge it.
The practical consequences run deep. A distributed system with nodes on different smearing schedules, or a mix of smearing and stepping nodes, is observing incompatible clocks even when NTP reports synchronization. SI-second stability matters for cryptographic timestamps, database ordering guarantees, and scientific instrumentation. Monotonicity matters for cron, billing, and log correlation. NTPv5's leap-smeared UTC flag does not resolve this tension—it merely makes it explicit.
Windows Time service, for its part, cannot explicitly inject leap seconds when acting as an NTP server. Windows-centric fleets have historically relied on upstream smearing or stepped corrections from Linux and stratum-1 sources—a dependency chain that NTPv5's new timescale signaling makes visible but does not simplify.
The leap second's abolition in 2035 will close one era and open another. The question for operators now is not which strategy is correct—both are fundamentally broken in different ways—but whether their fleets can survive one more discontinuity before the era ends.
Sources:
– draft-ietf-ntp-ntpv5-09, "Network Time Protocol Version 5"
– NTP Leap Second: Leap Indicator, Smear vs Step & Operator Retrospective
– Microsoft Learn: How Windows Time service treats leap second
– Wikipedia: Leap second