What causes changes in the rate of rotation of the earth?
Earthquakes, nuclear explosions, tectonic plate activity, the moon slowly moving away from us amongst other causes.
Leap second hiatus
31–40 of 117 posts
Re: Leap second hiatus
#32Earlier 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.
> 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
#33Re: Leap second hiatus
#34Time related stuff sure is messy.
Re: Leap second hiatus
#35There'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.
Re: Leap second hiatus
#36Monotonically rising time with a negative leapsecond...
Uniquely specifying the four times in the first sequence as UNIX timestamps isn't strictly possible, but it is possible with negative leap seconds.
Re: Leap second hiatus
#37Can 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…
Re: Leap second hiatus
#38What causes changes in the rate of rotation of the earth?
[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.
Re: Leap second hiatus
#39Can 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…
Re: Leap second hiatus
#40> 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…
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).