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

51–60 of 117 posts

Re: Leap second hiatus

#51

Post by zokier »

bhk wrote: post #27
dgrin91 wrote: post #18

Earlier quoted context omitted.

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 Ea…

> Leap seconds were a terribly misguided idea.

I prefer dropping leap seconds, but I wouldn't call them misguided. UTC and leap seconds come from maritime celestial navigation, where tracking rotation is actually important. Civil time then just piggybacked on that, which at the time probably was perfectly reasonable solution.

Re: Leap second hiatus

#53

Post by Jestar342 »

zokier wrote: post #49
wyattpeak wrote: post #24

Earlier quoted context omitted.

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 it…

As a former developer of software for an international shipping company: Yup. They happen a lot more frequently than most people realise, I expect. Political reasons (e.g. neighbouring states [as in Sovereign] deciding to unify timezones), coups/wars suspending DST, and so on all usually result in some kind of adjustment, even if it's just the name of the timezone changing.

Re: Leap second hiatus

#54

Post by contravariant »

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.

Now this is going to sound crazy but what if we just extend the year by a few seconds by default? Then we can just skip seconds as needed.

Re: Leap second hiatus

#55

Post by weinzierl »

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.

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

Why not just use TAI for almost everything and leave UTC (including regular leap seconds) for applications that need it?

Re: Leap second hiatus

#56

Post by fanf2 »

zokier wrote: post #49
wyattpeak wrote: post #24

Earlier quoted context omitted.

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 it…

Yes, I think that would make sense, but leap hours would be very rare: the first one won’t be needed for 500 years. See the first table at https://www.ucolick.org/~sla/leapsecs/dutc.html

But, leap hours don’t need to be co-ordinated: countries can and do change their clocks to adjust the time of sunrise when they want.

And leap hours will work much longer than leap seconds: leap seconds will become too frequent in 1 or 2 thousand years, but leap hours will just be getting started. See the second table at the same link https://www.ucolick.org/~sla/leapsecs/dutc.html

Re: Leap second hiatus

#57

Post by nemetroid »

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.

The more infrequent your deployments, the more difficult they will be.

Re: Leap second hiatus

#58

Post by bloak »

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.

People who can't cope with leap seconds should stop pestering the people who define UTC and just switch to TAI. They can do that now. No one is stopping them. Leap seconds are a pain and I myself would happily choose TAI over UTC for the system clock on a typical embedded system.

However, for civil time keeping and for some technical purposes, UTC as currently defined is exactly what we need. Don't fuck with it.

Re: Leap second hiatus

#59

Post by welterde »

Dylan16807 wrote: post #29
dgrin91 wrote: post #18

Earlier quoted context omitted.

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.

Pretty much all telescopes (under computer/time control) on this planet rely on UTC being quite close to UT1, since every second difference leads to a 15 arcsecond error in the pointing of the telescope (error between where you want to point the telescope on the sky and where you are actually pointing).

While <5s is usually not a problem (except for some instruments with very very small FoV), at 30s it really becomes a problem for instruments with modest fields of view.

Re: Leap second hiatus

#60

Post by saurik »

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.

That seems like it would be obvious, though, so people would fix it.
Post reply on HN