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.
- _alternator_
You may be relived to know that Unix epoch time does not have this problem. But you may also be horrified to know why.
First, epoch seconds are not the numbers of seconds since 1970/01/01. This is a lie we tell to children. Rather, epoch seconds are the number of days since 1970/01/01 * 86400 plus the number of seconds since midnight.
Leap seconds, to epoch time, don't exist. Or maybe they are double counted. Or maybe we smear them over 12 or 24 hours (but which 12 or 24 hours depends on whether you are Google, Microsoft, or Oracle; I can't even make this stuff up). The point is, it's not defined, and this means implementations do it differently.
A negative leap second might be easier though. The spec suggests (though lack of speaking) that a correct implementation will just skip it since number of seconds stays less than 86400 for that day. But of course the smear-organizations still smear it.
So what if you really want to know how many seconds were between two different epochs? Subtracting epoch seconds is wrong because you need to correct for the number of leap seconds between the two times.
And the smears.
- Bender
Google's proposal is a smear. [1] 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 [2] were fixed specifically to deal with going backwards.
- wmf
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.
- SeanAnderson
I don't think we're going to do any negative leap seconds.
https://www.yahoo.com/news/science/articles/international-ti...
I think we're voting to change to a leap hour in early 2027. Or I'd assume we're going to go that route instead of continuing to entertain the tech nightmares.
- aomix
Not responsible for those systems.
The last time this came up I thought “smearing” the second over the course of a day kind of solved the problem a discrete +/- 1 second suddenly appearing on the clocks.