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.
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 time, the outliers will only be off by a minute. Not so bad.)
A leap-hour, meanwhile: That kicks the can so far down the road that we'll probably lose track of it completely. 600 years is a very long time; society will be a very thing by then. Leap-hours seem to me to be moral equivalent to the "fuck it, let's just give up" option.
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.
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.
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.
> gettimeofday() should never be used to measure time
And yet, even as somebody who has no idea what platform you're referring to, I can still guarantee you that gettimeofday() is used to measure time on that platform. This is how software works, unfortunately.
The Earth's rotation is slowing down in the long term, hence the need to adjust. In the short term (where 10 years is "short") it can speed up or slow down, but long-term it is slowing down.
Note that this is not an argument for leap seconds - just my understanding of their rationale.
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.
I'm pretty sure that's the plan. Currently they're legally bound to keep it within 0.9s of solar noon (or something like that) but in 2035 it's changing to +-1 minute, which basically kicks the can down the road for another century or so
I say we let it reach 15 minutes then countries can solve it themselves by shifting timezone by 15 mins. Since making sure solar noon matches noon on the clock, is the point of timezones existing in the first place
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.
I wonder if there's things that run 24/7 and need to be monitored.. e.g. if you have oil flowing through some pipeline at 100 liters/second, one particular minute will have 6100 liters, and someone will want to get paid for that 100 extra liters.
But the meter/reporting tool would say "Well, we measure every second, and the meter reported a constant rate of 100 liter/second, and as we know we have 60 seconds in a minute, so we got 6000 liters!".
Or a database for "measurements every second for this minute" that has 60 fields, and don't have a field for the 61st measurement.
I once worked with smart meters for electricity consumption that do run 24/7. Leap seconds were not an issue but we had a very similar one now that I think about it: DST shenanigans!
Like how much time is there between 2 and 3 am? Usually one hour, but sometimes 2 and also sometimes 0. It looks simple at first but it creates a lot of edge cases that your business logic now needs to handle and we had a fairly complex system for this.
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.
The problem frequently crops up in order-deterministic systems that use time and haven't accounted for the edge case of all the vagaries related to time-keeping of this being only one.
I've worked on some extremely sensitive systems that had thousands of lines of C dedicated to handling skewing a time gap across an hour-per-second when necessary. I know that code assumed only "missing" time (jump-forwards)... Even knowing what I know as a developer now, if I was re-implementing that system from scratch and didn't have this top-of-mind, I'd bet I would miss "overlapping" or "duplicate" time entirely.
Maybe that is more of a me problem than others, but I'd bet there are some safety critical systems out there where the responsible engineers, QA, and specs all missed this as well.
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.
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.
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.
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
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.
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."
* https://lists.freebsd.org/pipermail/freebsd-stable/2020-Nove...
Of course third-party userland code understanding what happens is another thing.
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.
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 time, the outliers will only be off by a minute. Not so bad.)
A leap-hour, meanwhile: That kicks the can so far down the road that we'll probably lose track of it completely. 600 years is a very long time; society will be a very thing by then. Leap-hours seem to me to be moral equivalent to the "fuck it, let's just give up" option.
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.
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-...
And yet, even as somebody who has no idea what platform you're referring to, I can still guarantee you that gettimeofday() is used to measure time on that platform. This is how software works, unfortunately.
Note that this is not an argument for leap seconds - just my understanding of their rationale.
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.
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.
I say we let it reach 15 minutes then countries can solve it themselves by shifting timezone by 15 mins. Since making sure solar noon matches noon on the clock, is the point of timezones existing in the first place
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.
But the meter/reporting tool would say "Well, we measure every second, and the meter reported a constant rate of 100 liter/second, and as we know we have 60 seconds in a minute, so we got 6000 liters!".
Or a database for "measurements every second for this minute" that has 60 fields, and don't have a field for the 61st measurement.
Like how much time is there between 2 and 3 am? Usually one hour, but sometimes 2 and also sometimes 0. It looks simple at first but it creates a lot of edge cases that your business logic now needs to handle and we had a fairly complex system for this.
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.
I've worked on some extremely sensitive systems that had thousands of lines of C dedicated to handling skewing a time gap across an hour-per-second when necessary. I know that code assumed only "missing" time (jump-forwards)... Even knowing what I know as a developer now, if I was re-implementing that system from scratch and didn't have this top-of-mind, I'd bet I would miss "overlapping" or "duplicate" time entirely.
Maybe that is more of a me problem than others, but I'd bet there are some safety critical systems out there where the responsible engineers, QA, and specs all missed this as well.
[1] - https://developers.google.com/time/smear
[2] - https://rivassec.com/leap-second-chaos-2012.html
As far as the computers were concerned, nothing was different.
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.
By any other standard, most manually set clocks are up to a full minute off all the time.
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.
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."
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.