Join the discussion
Write your take first — we'll ask for email only when you're ready to publish.
- Hacker News
- Fortunately, in the past couple months, the likelihood of actually needing a negative leap second in the next few years has been trending down. This is based on measurements and predictions done by the IERS, the data for which they publish weekly in their Bulletin A [0]. I've been tracking this data for a while, and their DUT1 predictions have been trending more negative over the past few months, suggesting that the anticipated negative leap second is likely to be delayed, or it may very well not happen at all.
[0] https://datacenter.iers.org/data/latestVersion/bulletinA.txt
by ls65536 - 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.by deepspace
- 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.by ls65536
- I'm rooting for pure UTC never adjusted to actual sidereal days. Let me wake up at 1600 and go to sleep at 800, it's fine.by jaggederest
- 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-...
- by ivanjermakov
- > 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.
- Since the whole leap second system will be phased out by 2035 anyways I doubt that anyone will test it. No need to rock the boat over a second.
- 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.
by dgrin91 - traditional markets are closed when time changes happenby not-a-llm
- 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.
by TrueDuality - 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.by wat10000
- 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.
by chaps - 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.
by netsharc - If we have positive and negative leap seconds, why are we doing anything at all? 1 second forward, just to go 1 second back 10 years later…by al_borland
- 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.
by yen223 - 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.
by aomix - 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.
by repsilat - 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.
by SeanAnderson - 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 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. ~6,000 years is a very long time; society will be a very different thing by then. Leap-hours seem to me to be moral equivalent to the "fuck it, let's just give up" option.
edit: accidentally a word, and fixed an off-by-an-order-of-magnitude error on the approximate years required for a leap hour
by ssl-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.by wmf
- negative leap seconds aren't too bad. jumping forward a second won't lead to a time loop like jumping back did on several systems (some twice!)by toast0
- Explain why negative leap seconds are worse? Intuitively it seems like normal leap seconds would cause way more issues, or at least not more.by voxic11
- 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.by knorker
- 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.by Bender
- 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 themselvesby ikiris
- 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.
by eqvinox - 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.
by yen223 - 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.
by _alternator_