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

21–30 of 117 posts

Re: Leap second hiatus

#21

Post by im3w1l »

dgrin91 wrote: post #18
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.

Pretty sure there are lots of things that you use everyday that actually require precision time, such as GPS.

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

Re: Leap second hiatus

#22

Post by brandmeyer »

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.

Pretty 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

Re: Leap second hiatus

#23

Post by mormegil »

dgrin91 wrote: post #18
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.

Pretty sure there are lots of things that you use everyday that actually require precision time, such as GPS.

GPS does not use leap seconds. See e.g. https://en.wikipedia.org/wiki/Global_Positioning_System#Leap...

Re: Leap second hiatus

#24

Post by wyattpeak »

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 fifth of the way to the next one (not to mention the timestamp bug one coming up in a decade).

I disagree with the other comment's suggestion that leap hours can be taken into consideration like DST. I see no reason why DST code (which is generally implemented as an extra timezone) could straightforwardly be adapted to handle a single permanent shift of time.

Re: Leap second hiatus

#25

Post by nitrogen »

dflock wrote: post #16

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

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

Re: Leap second hiatus

#27

Post by bhk »

dgrin91 wrote: post #18
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.

Pretty sure there are lots of things that you use everyday that actually require precision time, such as GPS.

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

Re: Leap second hiatus

#28

Post by lifthrasiir »

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…

> I see no reason why DST code (which is generally implemented as an extra timezone) could straightforwardly be adapted to handle a single permanent shift of time.

The point is that we don't have to add the additional code to handle leap hours, as it can be implemented as a large swath of time zone changes.

We can imagine that there would be two versions of UTC, one before the leap hour (hereafter UTC) and one after the leap hour (hereafter UTC'). After the leap hour UTC and UTC' will coexist, where UTC' = UTC-1. Since time zone definitions themselves have UTC offsets, the trick is that instead of replacing all occurrences of UTC with UTC' (so that they would have UTC' offsets) we replace those offsets to have the same net effect. For example EST is UTC-5 before the leap hour and UTC'-5 = UTC-6 after the leap hour, so we pretend that the definition of EST changed to UTC-6.

Note that this approach essentially fixes the UTC-TAI offset (as opposed to the UTC'-TAI offset) and makes UNIX timestamp (time_t) deviate from the current version of UTC (well, UTC'). I believe this is just a matter of definition and thus much doable than changing UTC every few year. After all, leap hours would be much rare, probably the first one would occur at least a few centuries later.

Re: Leap second hiatus

#29

Post by Dylan16807 »

dgrin91 wrote: post #18
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.

Pretty sure there are lots of things that you use everyday that actually require precision time, such as GPS.

Precision isn't a binary, it's a continuum. The question at hand is whether there are significant use cases where 1 second of slack in matching the Earth's rotation is acceptable, but 30 seconds is too much.

GPS isn't an example of that because 1 second is already a quarter mile off.

Post reply on HN