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.
Ask HN: Are systems ready for the first negative leap second?
21–30 of 100 posts
Re: Ask HN: Are systems ready for the first negative leap second?
#22Re: Ask HN: Are systems ready for the first negative leap second?
#23I wonder how many systems actually care? I presume the core NTP servers handle this well, and most systems just feed off of that? GPS satellites probably handle it well too, but maybe some consumer or even industrial GPS receivers don't? Maybe some trading systems? I don't think crypto systems care too much.
Re: Ask HN: Are systems ready for the first negative leap second?
#24I wonder how many systems actually care? I presume the core NTP servers handle this well, and most systems just feed off of that? GPS satellites probably handle it well too, but maybe some consumer or even industrial GPS receivers don't? Maybe some trading systems? I don't think crypto systems care too much.
Was involved in rolling out a large NTP annealing patch about ten years ago. We missed a couple and the effect was largely overall muted, but we did have one server with an old JVM hard crashing the server right at the second shift.
That specific server was already hobbling along so it wasn't a surprise. But it required a bit of firefighting.
Re: Ask HN: Are systems ready for the first negative leap second?
#25Systems 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.
Re: Ask HN: Are systems ready for the first negative leap second?
#26Google'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 . [1] - https://developers.google.com/time/smear [2] - https://rivassec.com/leap-second-chaos-2012.html
Re: Ask HN: Are systems ready for the first negative leap second?
#27Earlier quoted context omitted.
The brilliant thing about the smear is that it distributes the new second across each second of the day, so that each second differed by 1/86400 seconds, well within the margin of error for NTP. As far as the computers were concerned, nothing was different.
The less brilliant thing about the smear is that if your ntpd syncs from smeared and unsmeared servers, the results aren't great. It would have been better if they would have kept the time on the wire accurate or added mandatory protocol stuff to avoid confusing things for ntpds configured to different leap second handling.
Re: Ask HN: Are systems ready for the first negative leap second?
#28Re: Ask HN: Are systems ready for the first negative leap second?
#29We'll just get some poorly coded stuff claim that an operation took 1100ms instead of 100ms. Not great, but not -900ms.
Well, I say that, but per my link here F5 load balancers at least used to keep track of TCP connections using gettimeofday. And it's annoying that libpcap delivers metadata in wallclock time.
[1] https://blog.habets.se/2010/09/gettimeofday-should-never-be-...