Ask HN: Are systems ready for the first negative leap second?
It has been 10 years since the last leap second, and we are now approaching the first negative leap second. I am concerned about whether current systems are prepared to handle this event. Are there known risks or preparations needed for this upcoming change?
"Systems are absolutely not ready. Leap seconds are a bad idea and negative leap seconds are worse. Just don't do it and let the drift cancel out."
"Google's proposal is a smear. Most time servers do not use smear. No idea what behavior it may introduce in places where sub-second time is important. Curious if all these bugs were fixed specifically to deal with going backwards."
"NTP. By any other standard, most manually set clocks are up to a full minute off all the time."
"Yeah, but we're thinking of systems where nanoseconds matter. MiFID 2 alone forces sub-μs precision. Million times less than the leap 1 second. NTP minute away is good for displaying date on the workstation, not for many of the devices that are critical to the modern world."
"Yesno. Sure they have their own time servers fed from the GPS, but they need to be accurate in relation to the world. But timestamps used by companies forced to use very accurate timing must be synchronised to UTC."
HN discussion
- Negative leap seconds are technically less dangerous than positive ones because they cause time to jump forward rather than backward, avoiding the time loops that previously crashed systems like F5 load balancers and old JVMs.
- The leap second system is likely to be phased out by 2035 in favor of a larger 'leap hour' adjustment or a widening tolerance window, making immediate preparation for a negative leap second unnecessary.
- While 'smearing' the leap second over 24 hours solves issues for most systems, it creates synchronization conflicts if an NTP client receives data from both smeared and unsmeared servers simultaneously.
- Financial regulations like MiFID 2 mandate microsecond or nanosecond precision, forcing critical trading systems to handle time anomalies rigorously, whereas many other systems only require millisecond accuracy or use internal monotonic clocks.
- Business logic for continuous processes, such as utility metering or pipeline flow rates, often fails to account for the 61st second, leading to billing discrepancies or database schema errors when a minute contains 61 seconds.