Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Leap second hiatus

fanf.dreamwidth.org

Post reply on HN
Print view View original

41–50 of 117 posts

Re: Leap second hiatus

#41

Post by beagle3 »

centimeter wrote: post #7
dudus wrote: post #5

Earlier 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.

> 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.

Unfortunately, almost everything is UI code in some way, so this won't be cleaned up.

The problem with TAI is that you cannot convert a future time to UTC if it is farther than 6 months or so in the future (because leap seconds have not been decided), so unless it never needs any conversion to/from UTC, you can't use it. (are logs UI? is crontab UI? eventually everything is)

Furthermore, you can't build an embedded no-need-to-update-every-6-month system with available common protocol - you would need to continuously feed it the list of leap-seconds, for which AFAIK there is no widely deployed protocol.

But if you use UTC, there are many protocols (TIME, NTP, SNTP, PTP), at least one of which you'll use anyway because of clock drifts, that will let you keep working.

Re: Leap second hiatus

#43

Post by toast0 »

etxm wrote: post #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?

Linux 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)

Re: Leap second hiatus

#44

Post by lifthrasiir »

beagle3 wrote: post #41
centimeter wrote: post #7

Earlier quoted context omitted.

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.

> 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. Unfortunately, almost everything is UI code in some way, so this won't be cleaned up. The problem with TAI is that you cannot convert a future time to UTC if it is farther than 6 months or so in the future (because leap seconds have not been decided), so…

> The problem with TAI is that you cannot convert a future time to UTC if it is farther than 6 months or so in the future [...]

Centimeter's argument is that such time should not be converted to TAI in advance, much like the local time for the future point (since the local time zone offset may change). All points on this also apply to the local time, e.g. it's already true that non-updatable embedded systems can't reliably do the local time calculation.

Re: Leap second hiatus

#45

Post by kqr »

japanuspus wrote: post #38
dflock wrote: post #16

What causes changes in the rate of rotation of the earth?

The 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 "ear…

> change in the angular momentum carried by oceans and atmosphere

...and some liquid (or at least semi-liquid) stuff beneath the crust?

Re: Leap second hiatus

#46

Post by [deleted] »

wmf wrote: post #14
kqr wrote: post #13

Earlier quoted context omitted.

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.

[deleted]

Re: Leap second hiatus

#47

Post by zokier »

wyattpeak wrote: post #24
labster wrote: post #15

Can 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.

Besides the sibling comment that some things rely on the days being synced to rotation, doing it once a century would pretty much guarantee that only the most obsessively robust systems would take it into consideration when being built. We'd be giving ourselves a Y2k-equivalent to deal with every century. Maybe that's not the biggest deal in the world, but I still remember the last viscerally and we're already a fift…

> Besides the sibling comment that some things rely on the days being synced to rotation

Examples would be great. Especially examples of things relying civil time to track rotation.

Re: Leap second hiatus

#48

Post by BlackFly »

centimeter wrote: post #9

Many 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'…

This argument naturally leads to the conclusion that you should basically never use UTC. So you use a singularity free coordinate for machine storage of times, TAI, but most users will want those displayed in their local times and nobody is using UTC. UTC is just an intermediate time, computed using leap seconds from TAI that you use on your way to a local time. But you could just remove that step.

Seems sensible to me actually. I don't really see why I would personally want to ever use UTC over TAI or local time. Sadly, a lot of time libraries don't seem to expose TAI as easily as they expose UTC, which I guess is why I continue to use UTC.

Re: Leap second hiatus

#49

Post by zokier »

wyattpeak wrote: post #24
labster wrote: post #15

Can 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.

Besides the sibling comment that some things rely on the days being synced to rotation, doing it once a century would pretty much guarantee that only the most obsessively robust systems would take it into consideration when being built. We'd be giving ourselves a Y2k-equivalent to deal with every century. Maybe that's not the biggest deal in the world, but I still remember the last viscerally and we're already a fift…

> doing it once a century would pretty much guarantee that only the most obsessively robust systems would take it into consideration when being built.

tzdata updates happen all the time (in a relative sense). So code would need to handle those, and I don't see why potential leap hours couldn't be handled like that. Just means that Europe/London eventually will be +01:00 (or is it -01:00, anyways) instead of +00:00 its now.

Re: Leap second hiatus

#50

Post by ggm »

repsilat wrote: post #36
ggm wrote: post #33

Monotonically rising time with a negative leapsecond...

Actually 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.

phew!
Post reply on HN