> 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?
I was at Twitter when lots of machines seized.
Leap second hiatus
11–20 of 117 posts
Re: Leap second hiatus
#12Leap 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.
Yes, the satellites should know 6mo in advance. UTC is still a head ache though.
Re: Leap second hiatus
#13Many 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'…
Why 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!
Re: Leap second hiatus
#14Many 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'…
Why 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!
You know in some places they will forget the conversion so you'll have weird cases that are off by 37 seconds.
Re: Leap second hiatus
#15Can 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.
Re: Leap second hiatus
#16What causes changes in the rate of rotation of the earth?
Re: Leap second hiatus
#17Many 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'…
I 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.
Re: Leap second hiatus
#18Can 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.
Pretty sure there are lots of things that you use everyday that actually require precision time, such as GPS.
Re: Leap second hiatus
#19Earlier quoted context omitted.
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.
> 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-ge...
Re: Leap second hiatus
#20Can 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.
I'm a diehard proponent of leap hours [1]. We already have a regular (or, rather irregular) adjustment in the civil time, namely time zones and "daylight saving" times. While I passionately hate DST, if we have to have DST anyway it's much better to make UTC adjustments use the same increment as well.