10 ms·
Leap second hiatus
- mdpm 6y agoRe: the 'negative second' fears - in usual operation, NTP adjusts your local machine downward all the ... time. There's really nothing to be afraid of; a few services would implement some skew, the rest of us would get NTP updates and life continues.
- woahAcademia 6y agoWhat about my DIY double entry book system I wrote using various JavaScript libraries? I have no clue.
- macintux 6y agontpd can be configured to disallow negative time adjustments, and anything that runs a database definitely should have that configured. The system clock is presumed to always increment for most databases, and screwing with that can cause data loss.
- NovemberWhiskey 6y agoI think the concern is more about whether the negative leap second handling in all of the different, interacting NTP server implementations (which have never been exercised in the wild) will be good, bad or ugly. If you read around the topic, there was plenty of non-conformance for the relatively recent leap seconds. As you say, clock skewing happens continuously in NTP so that part looks proven.
- etxm 6y ago> NTP or kernel timekeeping code expects that it will be an appalling shitshow. I’m curious what systems would catastrophically fall apart if time went back one second?
- vimax 6y agoAbout 10 years ago all Java processes everywhere deadlocked because of this.
- teraflop 6y agoTechnically, that was a Linux kernel bug that Java happened to be heavily affected by: https://news.ycombinator.com/item?id=4188412 https://news.ycombinator.com/item?id=4188412
- dudus 6y agoDistributed alogrithms often depend on precise clocks to maintain consistency. See google spanner for instance. Updating the clock one second means taking a whole cluster offline untill you are sure the clocks are synchronized exactly before bringing them online again. It brings an outage and potential of headaches. If the clocks are not synchronized you break the consensus, might cause transactions to commit partially or cause inconsistent reads and writes.
- centimeter 6y agoThose algorithms should be using TAI, not UTC. Any distributed system that breaks in the presence of leap seconds is necessarily poorly designed. The fact that any non-UI code uses any time standard except TAI is a very unfortunate historical mistake that will hopefully be cleaned up over the next few years. Thankfully since 2013, Linux kernel has supported TAI.
- lifthrasiir 6y ago> Thankfully since 2013, Linux kernel has supported TAI. Only with the correct ntpd configuration [1]. For that reason it is impossible to rely on that API in end-user libraries. [1] https://superuser.com/questions/1156693/is-there-a-way-of-getting-correct-clock-tai-on-linux https://superuser.com/questions/1156693/is-there-a-way-of-ge...
- thayne 6y agoAnd from what I can tell it doesn't work with systemd-timesyncd, which many linux systems are using now.
- brandmeyer 6y agoPretty sure the Spanner case isn't using either one. Google's systems futz with the speed of time near the leap second to distribute it across a wide span about midnight, UTC. https://developers.google.com/time/smear https://developers.google.com/time/smear
- beagle3 6y ago
- rachelbythebay 6y agoA negative leap second (the appalling shitshow from the article) would make us skip a second, though. Going back one second is what generally happens now when a Linux box does the "inserting leap second" thing. It goes from 23:59:59.999999 to 23:59:59.000000, then runs that whole second again. You get to 23:59:59.999999 again, and then you finally roll over to 00:00:00.000000. From the perspective of the typical time_t rendering of Unix time, there is no way to uniquely represent that 61st second. It just "disappears". Having lived through systems going backwards some 17 seconds due to a botched NTP-GPS appliance config, I can tell you that what died at that particular site was all of the locking code that used wall time clocks instead of monotonic clocks. They all CHECKed and died when their preconditions were no longer valid. This didn't have to happen. They could have used monotonic from the get-go, and then they wouldn't have died when the clocks got yanked backwards 17 seconds to the proper time base.
- beagle3 6y ago> Having lived through systems going backwards some 17 seconds due to a botched NTP-GPS appliance config Well then, it really was botched. I was running an off-line hodge podge of 50 or so RH7.3 + Win2K systems back in 2002, where I had to manually fix the few second drift every couple of months, and the RH machines all slewed faster/slower to adapt, non ever went backward or jumped forward (Don't remember how the Win2K handled it; They weren't mission critical and I didn't care much).
- bogomipz 6y ago>'From the perspective of the typical time_t rendering of Unix time, there is no way to uniquely represent that 61st second. It just "disappears".' This is a great and really intuitive summary of the problem. Is there a certain class of problem related to disappearing second? Like are these more likely to be filesystem issues or things that rely on timestamps? Or are there second order problems as well? >"I can tell you that what died at that particular site was all of the locking code that used wall time clocks instead of monotonic clocks. They all CHECKed and died when their preconditions were no longer valid. I can tell you that what died at that particular site was all of the locking code that used wall time clocks instead of monotonic clocks. They all CHECKed and died when their preconditions were no longer valid." Sorry if this is a silly question but was that check simply that "time t1 is greater than time t0"? Also was the duration of that outage(17 seconds) or would this have been equally catastrophic at a single second?
- spullara 6y agoI was at Twitter when lots of machines seized. https://www.wired.com/2012/07/leap-second-glitch-explained/ https://www.wired.com/2012/07/leap-second-glitch-explained/
- toast0 6y agoLinux had two different kernel bugs around this, IIRC. MySQL got confused too (although that one just ate cpu until you restarted the daemon, it didn't crash, and it didn't prevent service)
- Mountain_Skies 6y agoLeap seconds are such a pain. I understand why they cannot be allocated algorithmically but that doesn't make them any easier to deal with.
- centimeter 6y agoMany computer programs use UTC time (which means you have to deal with leap seconds) when they really should be using TAI (which is based purely on the physical progression of time on the earth's geoid, with no arbitrary input that has to be updated periodically). https://cr.yp.to/proto/utctai.html https://cr.yp.to/proto/utctai.html Generally, you should only be dealing with UTC for things that have to display/accept a time to/from human users; there's no reason for computers to reason about the interval between events using UTC.
- kqr 6y agoWhy is this downvoted? It sounds great to my untrained ear. You could even use TAI for user-facing timestamps (to get consistent arithmetic) and then convert to UTC only in the end before displaying the date!
- wmf 6y agoYou know in some places they will forget the conversion so you'll have weird cases that are off by 37 seconds.
- lifthrasiir 6y agoI hear this argument quite a lot. But using TAI is no different from using UTC in terms of complexity because both requires the complex problem of data distribution (either of leap seconds or of UTC-TAI differences). If you ever have to use UTC somewhere you can't escape from that problem; using TAI is only moving the goalpost.
- labster 6y agoCan we take a longer hiatus on leap seconds, maybe 79 years or so, and only update once a century? Local apparent noon being off by 30 seconds or so has approximately zero impact on my daily life, but stupid things in datetime libraries do occasionally have impact. If we can’t throw off the oppression of UTC and greet TAI as liberators, at least adjust the clock at regular, very infrequent dates.
- dgrin91 6y agoPretty sure there are lots of things that you use everyday that actually require precision time, such as GPS.
- im3w1l 6y agoAs long as everyone agrees on the time GPS will work. It's a question of how much deviance from solar time we are willing to tolerate vs how much effort we want to tolerate.
- mormegil 6y agoGPS does not use leap seconds. See e.g. https://en.wikipedia.org/wiki/Global_Positioning_System#Leap_seconds https://en.wikipedia.org/wiki/Global_Positioning_System#Leap...
- bhk 6y agoLeap seconds have nothing to do with precision time. It's a non-periodic alteration to the definition of UTC. Those niche applications that require second-accurate knowledge of Earth's rotational accuracy don't need to rely on leap second changes to UTC; they could get that information out of band, and will need to anyway when they need sub-second accuracy. The 99.999% of other applications that don't need to know Earth's rotation orientation relative to the sun within a second -- but do have to calculate time differences between two UTC times -- would be much better off not having to deal with leap seconds. Leap seconds were a terribly misguided idea.
- zokier 6y ago
- dflock 6y agoWhat causes changes in the rate of rotation of the earth?
- nitrogen 6y agoEarthquakes, movement of tectonic plates, etc. can shift the mass of the earth closer to or further from center. This speeds up or slows rotation, like when you are spinning in a chair and pull your arms in. Some energy is probably also lost to tidal friction with the moon.
- becauseiam 6y agoEarthquakes, nuclear explosions, tectonic plate activity, the moon slowly moving away from us amongst other causes.
- 317070 6y agoI don't think nuclear explosions belong in that list. They have tremendous power, but very limited energy on a planetary scale. Do you have a source that says otherwise?
- japanuspus 6y agoThe angular momentum of the "earth system" is constant [1]. The variation in angular velocity of the solid earth can be ascribed to change in the angular momentum carried by oceans and atmosphere. These changes can be due to change in velocity (winds, currents) or moment of inertia (moisture in atmosphere). [1] If we ignore friction due to tidal forces from moon and sun (which is valid on these time-scales), the "earth system" is not affected by any non-central forces and so the angular momentum is constant.
- RedShift1 6y agoInstead of inserting a leap second, can't we standardize leap smearing like Google does? https://developers.google.com/time/smear https://developers.google.com/time/smear. This will probably also work for negative leaps.
- ggm 6y agoMonotonically rising time with a negative leapsecond...
- repsilat 6y agoActually the negative leap second is "more monotonic" than the regular one. Normally a leap second adds an extra second (58, 59, 60, 00), but a negative leap second skips one (58, 00). Uniquely specifying the four times in the first sequence as UNIX timestamps isn't strictly possible, but it is possible with negative leap seconds.
- ggm 6y agophew!
- contravariant 6y agoNow this is going to sound crazy but what if we just extend the year by a few seconds by default? Then we can just skip seconds as needed.
- Tepix 6y agoJust because everyone seems to be complaining about leap seconds: I think they are the right solution for the problem. I do hope we won't need a negative leap second, that would break a lot of code for sure. Time related stuff sure is messy.
- throw0101a 6y ago> I do hope we won't need a negative leap second, that would break a lot of code for sure. Someone ended up asking on one of the FreeBSD mailing lists, and it seems that they test for it: * https://lists.freebsd.org/pipermail/freebsd-stable/2020-November/092837.html https://lists.freebsd.org/pipermail/freebsd-stable/2020-Nove... So at least when it comes to the FreeBSD kernel and ntpd, there's nothing to worry about there. Userland code may be a different matter of course.
- Slix 6y agoAren't the people in charge of UTC discussing never having a leap second ever again?
- forgotmypw17 6y ago> At the moment the Earth is rotating faster than in recent decades: these shorter days, with a lower length-of-day, means the milliseconds accumulate more slowly, and we get fewer leap seconds. Does anyone know why Earth's rotation has sped up?
- btilly 6y agoThe biggest factor is thought to be core-mantle coupling. The Earth is built in layers. The solid bit we see is called the crust. Then there is a liquid layer where heat melts rock, that's called the mantle. And then at the center of the Earth the pressure again turns things solid, that's called the core. All of the things affecting the Earth's rotation in the long term pull on the crust. The two biggest are tides (slows us by 2.3 ms/century) and glacial rebound (estimated to speed us up by 0.7 ms/century). The result is that the crust and the core wind up turning at different rates, and interact with each other through the mantle. Which transfers angular momentum back and forth between the crust and core. The article that first showed this is https://www.nature.com/articles/333353a0 https://www.nature.com/articles/333353a0 if you want to look further.
- kangnkodos 6y agoThis is great news! No leap second in 2020. It won't be a second longer than necessary.
- ay 6y agoWe should have two “keep on your toes” leap seconds per year, one +1 and one -1 (can it be done ?) in lieu of daylight savings time or together with it for those that still keep it.
- deleted 6y ago[deleted]
- quercusa 6y ago'in PostgreSQL you can use “allballs” in a time literal as an alias for midnight' Learned something new today!