5 ms·
Ask HN: Are systems ready for the first negative leap second?
It’s been 10 years since we had the last leap second and it looks like we will get the first negative one soonish. Are systems ready for that?
- d00d0ff000 3mo agoNTP. By any other standard, most manually set clocks are up to a full minute off all the time.
- subscribed 3mo agoYeah, 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.
- cyanydeez 3mo agodont most systems that rely on sharp timing simply manage it themselves.
- subscribed 3mo agoYesno. 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.
- dmurray 3mo agoMiFID 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."
- subscribed 3mo agoI 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.
- wmf 3mo agoSystems 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.
- toast0 3mo agonegative 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!)
- lokar 3mo agoUnless you have something scheduled for that second.
- thomashabets2 3mo agoIn a "realtime system", sure. But for almost all workloads programs have to deal with overshooting. Like, maybe CPU overloaded or swap intensity caused that second to "disappear". On almost all workloads you can't just assume that you'll execute on every single second. And if you do need to be scheduled on every second, well you always needed to use a monotonic time. Negative leap second should only cause measurements to be off by a second, at worst. Added leap seconds means time goes backwards, which is worse. Of course NTP can cause either.
- knorker 3mo agoWhat'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.
- gmuslera 3mo agoSuppose being charged by time used to run your tasks. Then your task takes -1 second, you will be charged zero, 1 second, or 18 quintillon seconds?
- Bender 3mo agoGoogle'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 https://developers.google.com/time/smear [2] - https://rivassec.com/leap-second-chaos-2012.html https://rivassec.com/leap-second-chaos-2012.html
- yen223 3mo agoThe 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.
- toast0 3mo agoThe 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.
- not-a-llm 3mo agoif you need below 1 millisecond time accuracy, probably you know what you are doing and you wont mix NTP servers (and I think you need PTP for that)
- chaps 3mo agoYou'd think so. Legacy servers that've been running for ten years really puts a hitch in that.
- lesam 3mo agoUntil 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).
- rezvovmobile 3mo ago[flagged]
- al_borland 3mo agoIf 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…
- yen223 3mo agoI 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.
- jMyles 3mo agoWe 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.
- StevenWaterman 3mo agoI'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
- repsilat 3mo ago> 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?
- happytoexplain 3mo ago
- dgrin91 3mo agoI 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.
- not-a-llm 3mo agotraditional markets are closed when time changes happen
- TrueDuality 3mo agoThe 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.
- netsharc 3mo agoI 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.
- blaze33 3mo agoI 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.
- aomix 3mo agoNot 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.
- repsilat 3mo agoI 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.
- deepspace 3mo agoWasn'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.
- ls65536 3mo agoThere'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.
- deleted 3mo ago[deleted]
- thomashabets2 3mo agoI'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-used-to-measure-time.html https://blog.habets.se/2010/09/gettimeofday-should-never-be-...
- happytoexplain 3mo ago> 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.
- thomashabets2 3mo agoAs per my linked blog post…
- ivanjermakov 3mo agoRelated: https://news.ycombinator.com/item?id=32548085 https://news.ycombinator.com/item?id=32548085
- BadBadJellyBean 3mo agoSince 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.
- OsrsNeedsf2P 3mo agoDon't systems regularly have this issue when they do time server syncs?
- crote 3mo agoNot quite. With a time sync your clock will jump, with a leap second it'll experience a minute with 59 or 61 seconds.
- SeanAnderson 3mo agoI don't think we're going to do any negative leap seconds. https://www.yahoo.com/news/science/articles/international-timekeepers-vote-changing-leap-040000515.html 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.
- ssl-3 3mo agoWe've on track to do something different before the end of 2035: https://en.wikipedia.org/wiki/Leap_second#Phase-out_and_future_of_leap_seconds 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
- DSMan195276 3mo ago> 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. Something to consider: The use of timezones in mostly 1-hour increments over inconsistently placed areas means that the vast majority of people are already living many minutes off from the "actual" time at their precise location, in some cases even more than an hour. "Giving-up" implies that this is something important worth maintaining, where-as for the vast majority of people they gain nothing from leap seconds or even leap minutes. The most important thing for people is simply that everybody agrees on what time it is, which is easier when leap-Xs aren't done. That said it's also probably true that a leap-hour would never actually happen, but that's not some big issue. By the time we got to the point that a leap-hour would make sense people would have already adjusted their habits and it probably wouldn't be worth it.
- m_m_carvalho 3mo ago[dead]
- throw0101a 3mo agoThe FreeBSD folks test their code for these things and it works: * https://lists.freebsd.org/pipermail/freebsd-stable/2020-November/092837.html https://lists.freebsd.org/pipermail/freebsd-stable/2020-Nove... Of course third-party userland code understanding what happens is another thing.
- jaggederest 3mo agoI'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.
- _alternator_ 3mo agoYou 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.
- stingraycharles 3mo agoAnd this, ladies and gentlemen, is why you use a proper datetime library rather than doing epoch arithmetic yourself.
- fragmede 3mo ago"How hard could it be?"
- SahAssar 3mo agoYes, it's wrong. But we have also agreed to all be wrong in the same way. Except during the specific day that we are wrong in different ways. Correction: We are mostly right, most of the time, but wrong in ways most people don't notice except if they try to talk while everyone is wrong. Clarification: Human perception of time is not understandable, and the machine abstraction even less so.
- FabHK 3mo agoIndeed. I like to say, we would like three things to be true: 1) Every day has 86400 seconds. 2) Every day is from noon (sun exactly above) to noon (sun exactly above). 3) We use SI seconds. You can't have all three. Pick any two: 1, 2, not 3: What you describe. Day has 86400 seconds, we keep in sync with the sun, but we tweak the seconds a bit. There are different versions, like epoch time, or UT1. 1, not 2, 3: Every day has 86400 SI seconds, and we slowly go out of sync with the sun. That's TAI. not 1, 2, 3: We use SI seconds and keep in sync with the sun +/- 1 second, but need to add/drop seconds occasionally. That's UTC. https://en.wikipedia.org/wiki/Universal_Time https://en.wikipedia.org/wiki/Universal_Time https://en.wikipedia.org/wiki/International_Atomic_Time https://en.wikipedia.org/wiki/International_Atomic_Time https://en.wikipedia.org/wiki/Coordinated_Universal_Time https://en.wikipedia.org/wiki/Coordinated_Universal_Time
- epsteingpt 3mo agoThis is gonna be so much better than Y2K!
- its_not_a_bug 3mo ago[dead]
- ak217 3mo agoNo and they shouldn’t be. Leap seconds were never a great idea and they become an increasingly worse idea with every passing year. They are a great example of a standards making decision made without sufficient negative feedback from its implementation costs.
- Faha_2011 3mo ago[flagged]
- ls65536 3mo agoFortunately, 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 https://datacenter.iers.org/data/latestVersion/bulletinA.txt
- kasajian 3mo ago[flagged]