Leap second hiatus
fanf.dreamwidth.org
Leap second hiatus
1–10 of 117 posts
Re: Leap second hiatus
#2> 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?
Re: Leap second hiatus
#3Leap seconds are such a pain. I understand why they cannot be allocated algorithmically but that doesn't make them any easier to deal with.
Re: Leap second hiatus
#4> 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?
About 10 years ago all Java processes everywhere deadlocked because of this.
Re: Leap second hiatus
#5> 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?
Distributed 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.
Re: Leap second hiatus
#6> 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?
About 10 years ago all Java processes everywhere deadlocked because of this.
Technically, that was a Linux kernel bug that Java happened to be heavily affected by: https://news.ycombinator.com/item?id=4188412
Re: Leap second hiatus
#7> 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?
Distributed 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 partial…
Those 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.
Re: Leap second hiatus
#8> 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?
A 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.
Re: Leap second hiatus
#9Many 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
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.
Re: Leap second hiatus
#10Leap seconds are such a pain. I understand why they cannot be allocated algorithmically but that doesn't make them any easier to deal with.
Aren't leap seconds built into GNSS protocols? i.e. if you have a GNSS receiver, leap seconds will be accounted for in ZDA NMEA sentences.