Live data from Hacker News

Ask HN: Are systems ready for the first negative leap second?

news.ycombinator.com

21–30 of 100 posts

Re: Ask HN: Are systems ready for the first negative leap second?

#22
Wasn't there a recent discussion here, where it was pointed out that leap seconds are about to be phased out in less than 10 years' time? I would be extremely surprised if a negative leap second was implemented before then, given that IERS already balked at doing that several years ago.

Re: Ask HN: Are systems ready for the first negative leap second?

#23
post #14

I 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.

GPS uses its own time base that doesn't do leap seconds. For display purposes, the leap second offset to UTC is transmitted to the receivers and added to the displayed time if needed.

Re: Ask HN: Are systems ready for the first negative leap second?

#24
post #14

I 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.

Systems definitely care, especially in finance and trading systems.

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?

#25
post #3

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.

What's worse about negative leap seconds? The "experienced" time by systems will just look like they froze for a second. Added leap seconds are worse, surely, as time goes backwards.

Re: Ask HN: Are systems ready for the first negative leap second?

#26
post #4

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 . [1] - https://developers.google.com/time/smear [2] - https://rivassec.com/leap-second-chaos-2012.html

Yeah 90% of the time the simple solution is just use Google time and these problems are smeared away because they got burned enough internally they did it themselves

Re: Ask HN: Are systems ready for the first negative leap second?

#27
post #13
post #10

Earlier 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.

User error

Re: Ask HN: Are systems ready for the first negative leap second?

#29
I'd say yes we are ready. gettimeofday() should never be used to measure time[1], but at least with a negative leap second it's monotonic.

We'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-...

Post reply on HN