Live data from Hacker News

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

news.ycombinator.com

81–90 of 100 posts

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

#81

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.

There's an agreement to do something about leap seconds before 2035, either by allowing DUT1 to exceed its currently specified bounds (this is most likely) or by agreeing to simply not insert/delete leap seconds going forward (this is less likely). For certain bounds on DUT1 and at some timescale, these would be practically the same in terms of their effects on civilization, computing, etc. In any case, a decision will almost certainly be made much sooner than 2035, perhaps even before the next leap second insertion/deletion would need to take place under the present rules.

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

#82

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 mayb…

And this, ladies and gentlemen, is why you use a proper datetime library rather than doing epoch arithmetic yourself.

"How hard could it be?"

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

#83
post #40

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.

We've on track to do something different before the end of 2035: https://en.wikipedia.org/wiki/Leap_second#Phase-out_and_futu... Shifting to a leap-minute feels close-enough to me: We might get one every 50 or 100 years. A lot of us reading this today will never live to see a leap-minute, but it's close enough that we'll still have it collectively in-mind when it it needs to happen. (And if we screw it up at that tim…

One way of thinking about ignoring leap seconds is that it's like letting the effective prime meridian drift east/west. And a "leap hour" is kind of like a timezone change. In fact, you could just not have a centralized/coordinated leap hour, and let individual jurisdictions change their own timezones as they wanted, if they wanted noon to be closer to the daily solar peak.

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

#84
post #21

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.

I had an issue in a CI pipeline once where clocks on two different machines drifted out of sync, and it looked like an HTTP request went back in time (it had some validity from now until now plus some delta, and the second machine thought it arrived "before now"), validation failed, pipeline failed.

An unusual case, fragile design, but indicative of potential issues with more interesting timekeeping choices.

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

#85
post #18
post #11

Earlier quoted context omitted.

I don't think we can predict ahead of time whether we'll need a leap second or not If the question is "why bother syncing time to Earth's orbit around the sun at all", I don't have a good answer for that except at this point, it's tradition.

We can set some rasterization floor, such as like 3 minutes or something, and live with that. Correcting for a 3-minute offset every few millenia seems easier than trying to understand all this minutia about wobble and aquifer management and whatever else goes into a leap second.

> every few millennia

We'll feel awful silly having made any leap seconds if the robots kill us all in the next decade.

More seriously -- all of today's computers and probably all of today's software (not to mention many scientific and governmental institutions) will be gone in 500 years. Does it make sense to plan too far ahead?

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

#86
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

Leap smearing is amazing exactly until the moment you need to know whether you're leap smearing (because your seconds are 1.0000116s long, or the reverse). That instant, it turns from amazing into the worst godawful mess you can imagine.

Leap seconds can be stored and communicated, if you need it you can do the work and get it. Leap smearing, you're shit out of luck, especially if you're a developer and need to deal with systems operated by others.

If you're sure you'll never cross that moment and need to know you're in a smear, go ahead, it's great. Otherwise test yo' stuff with leap seconds and get bugs reported & fixed.

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

#87
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.

Better still, if Unix time tracked TAI (monotonically increasing every SI second), and Leap Seconds were handled in a distributed database much like time zones - possibly even the same one we all use anyway.

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

#88
post #75

Earlier quoted context omitted.

I am not an expert in Time systems but I imagine the problem is similar to daylight savings problems. With a leap second it's like putting the clocks forward an hour. With daylight savings, In your time series database you suddenly go from 0059 to 0200. 0100-0159 are missing, but that's fine. Most systems are fine with missing data, because we assume there will be occasional outages and such When you go the other dir…

Negative leap seconds mean we skip a second, normal leap seconds are the ones where we repeate a second.

Huh. TIL

That's really unintuitive. Thank you for letting me know

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

#89
post #34

Earlier quoted context omitted.

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.

MiFID 2 does not require nanosecond accuracy. It's something like 100 microseconds in the strictest case. Some MiFID reports require microsecond or perhaps nanosecond precision , but that's really just a formatting requirement "please write your timestamps with six figures after the decimal point."

I said, quote "MiFID 2 alone forces sub-μs precision", and not that it "requires nanoseconds accuracy". Put the strawman away.

It's not "something like 100μs", it's 100 times less: 1μs.

From a convenient QA:

> Algorithmic and high-frequency trading (HFT) firms must timestamp to 1 microsecond (μs) accuracy, synchronized to UTC. For venues and systematic internalisers executing algorithmic strategies, this microsecond-level precision is non-negotiable. Other investment firms trading on venues must achieve 1 millisecond (ms) accuracy.

No, precision means actually precision, not a length of a number.

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

#90
post #53

Earlier quoted context omitted.

Until you work in financial markets and you want to measure latency vs a bunch of other servers you don't own, all of whom pick different smears (and some of whom aren't sure in advance which smears).

financial markets dont trade when the smears happen (NYE)

Early in my career, I had to babysit our FX quoting app through the July 2015 leap second.

And some things do trade 24/7 (though I wish they wouldn't, one auction per minute during US east coast business hours would be totally sufficient for most US markets).

Post reply on HN