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

71–80 of 117 posts

Re: Leap second hiatus

#71

Post by lifthrasiir »

wyattpeak wrote: post #69
lifthrasiir wrote: post #28

Earlier quoted context omitted.

> 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 problem is not that changing the code is complicated. Changing code to accommodate four-digit years wasn't complicated. The problem is that you have to change every single piece of software which uses time. What you're proposing is exactly what I think needs to be avoided.

You would be right if vendors weren't able to deliver time zones in time. In practice they are, though with lots of headaches. We can just piggyback on the existing infrastructure of the time zone distribution with no additional cost.

Re: Leap second hiatus

#72

Post by lifthrasiir »

wyattpeak wrote: post #68
zokier wrote: post #49

Earlier quoted context omitted.

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

I can't speak to how different parts of society will interact in hundreds of years, but if today there were going to be a leap hour and programmers requested that we start considering London to be in +01:00, the chances of politicians or public agreeing with that request is nil.

Sure, we will randomly move the end of the DST from the last Sunday of October to the first Sunday of November and everyone will try to kill us, right? DST is the perfect example that we have a relative freedom in changing time zone offsets.

You are however right that this is a political matter requiring some (but I believe, reasonable) amount of coordination, but timekeeping is in many parts political anyway. Practically speaking countries would implement the change out of necessity and not because of agreements, as one hour deviation is significant enough.

Re: Leap second hiatus

#73

Post by adrian_b »

lifthrasiir wrote: post #17
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'…

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.

No, using TAI is simpler, because it is really the time that has passed since some origin. Therefore any operation performed with its values behaves as expected.

Neither UTC nor local times are times in the physical sense. At most you can say that they are times passed from a non-constant origin of time, which changes frequently and in an unpredictable mode for the future.

People always forget what UTC and local times really are and they very frequently make mistakes in their handling, especially for future events.

The foolproof way, as advocated by Bernstein and others, is to use only TAI for internal timekeeping and computation, and to convert to UTC or local times only the values that will be seen by human eyes.

I have done like this since many years ago, and it was always simpler for me. It would have been much simpler if this would have been a general practice, as that would have eliminated the useless conversions required for communication with other systems that use UTC, e.g. when using NTP.

Re: Leap second hiatus

#74

Post by wyattpeak »

lifthrasiir wrote: post #71
wyattpeak wrote: post #69

Earlier quoted context omitted.

The problem is not that changing the code is complicated. Changing code to accommodate four-digit years wasn't complicated. The problem is that you have to change every single piece of software which uses time. What you're proposing is exactly what I think needs to be avoided.

You would be right if vendors weren't able to deliver time zones in time. In practice they are, though with lots of headaches. We can just piggyback on the existing infrastructure of the time zone distribution with no additional cost.

I don't think this infrastructure you're relying on exists. A great deal of software isn't maintained at all. It was built once by a contractor and has been plodding along doing its work for decades.

Major software vendors won't have any particular trouble, but neither did they have any trouble in 2000. It's all the tail-end stuff which is in danger of breaking.

Re: Leap second hiatus

#75

Post by wyattpeak »

lifthrasiir wrote: post #72
wyattpeak wrote: post #68

Earlier quoted context omitted.

I can't speak to how different parts of society will interact in hundreds of years, but if today there were going to be a leap hour and programmers requested that we start considering London to be in +01:00, the chances of politicians or public agreeing with that request is nil.

Sure, we will randomly move the end of the DST from the last Sunday of October to the first Sunday of November and everyone will try to kill us, right? DST is the perfect example that we have a relative freedom in changing time zone offsets. You are however right that this is a political matter requiring some (but I believe, reasonable) amount of coordination, but timekeeping is in many parts political anyway. Practi…

> we have a relative freedom in changing time zone offsets

Who is we in this sentence? Programmers certainly don't, they have to report times and timezones in their software as the populace expects it to be reported. Governments can change timezones, but they're not going to, because the political cost of telling everyone that they're in a new timezone is greater than the political cost of telling programmers where to shove it.

Most of the public will see absolutely no reason why they should have to permanently change the timezone they're in for the sake of a one-time event. And honestly, even as a programmer who'd be doing the fixing, I agree that they're right.

Re: Leap second hiatus

#76

Post by lifthrasiir »

wyattpeak wrote: post #74
lifthrasiir wrote: post #71

Earlier quoted context omitted.

You would be right if vendors weren't able to deliver time zones in time. In practice they are, though with lots of headaches. We can just piggyback on the existing infrastructure of the time zone distribution with no additional cost.

I don't think this infrastructure you're relying on exists. A great deal of software isn't maintained at all. It was built once by a contractor and has been plodding along doing its work for decades. Major software vendors won't have any particular trouble, but neither did they have any trouble in 2000. It's all the tail-end stuff which is in danger of breaking.

It should be very visible to users that softwares are unable to keep with time zone changes anyway (including those due to the relocation). If they are able to keep up somehow, probably manually, then leap hours don't impose any additional requirement to them.

Or, you can abolish the time zone to make software developers very happy [1]. At the expense of everything else.

[1] https://qntm.org/abolish

Re: Leap second hiatus

#77

Post by lifthrasiir »

wyattpeak wrote: post #75
lifthrasiir wrote: post #72

Earlier quoted context omitted.

Sure, we will randomly move the end of the DST from the last Sunday of October to the first Sunday of November and everyone will try to kill us, right? DST is the perfect example that we have a relative freedom in changing time zone offsets. You are however right that this is a political matter requiring some (but I believe, reasonable) amount of coordination, but timekeeping is in many parts political anyway. Practi…

> we have a relative freedom in changing time zone offsets Who is we in this sentence? Programmers certainly don't, they have to report times and timezones in their software as the populace expects it to be reported. Governments can change timezones, but they're not going to, because the political cost of telling everyone that they're in a new timezone is greater than the political cost of telling programmers where t…

Governments absolutely can. The updates to tzdata [1] are full of arbitrary changes happening all around the globe, not just for a few weird countries. The example I quoted above is 2007 changes to the United State's DST and a perfect example that governments can push time zone changes with at most marginal perceived benefits. Also remember that the current proposal to abolish leap seconds itself was primarily arosen due to computing complications anyway. Programmers can (indirectly) affect the future of leap seconds than probably any other group else.

[1] https://github.com/eggert/tz/blob/master/NEWS

Re: Leap second hiatus

#78

Post by zokier »

wyattpeak wrote: post #74
lifthrasiir wrote: post #71

Earlier quoted context omitted.

You would be right if vendors weren't able to deliver time zones in time. In practice they are, though with lots of headaches. We can just piggyback on the existing infrastructure of the time zone distribution with no additional cost.

I don't think this infrastructure you're relying on exists. A great deal of software isn't maintained at all. It was built once by a contractor and has been plodding along doing its work for decades. Major software vendors won't have any particular trouble, but neither did they have any trouble in 2000. It's all the tail-end stuff which is in danger of breaking.

If you don't do any tzdata updates in a century then I can guarantee you that the application will be showing wrong local times anyways. Timezone changes happen. That is a already occurring thing.

And it's not like there is even hard deadline to do the changes, nor would it come unpredictably. If any schedule we set would seem problematic, the change can be deferred by another decade or two to get systems fixed if really needed.

Re: Leap second hiatus

#79

Post by lifthrasiir »

adrian_b wrote: post #73
lifthrasiir wrote: post #17

Earlier quoted context omitted.

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.

No, using TAI is simpler, because it is really the time that has passed since some origin. Therefore any operation performed with its values behaves as expected. Neither UTC nor local times are times in the physical sense. At most you can say that they are times passed from a non-constant origin of time, which changes frequently and in an unpredictable mode for the future. People always forget what UTC and local time…

Using TAI exclusively is simpler, but that's not the parent advocates (and neither do you, I believe).

Using TAI primarily and UTC in display has two main benefits that I consider marginal. The first is that the addition and subtraction is associative and transitive, but their use towards non-zoned wall clock timestamps like time_t is limited anyway; they normally operate on zoned date & time (e.g. "tomorrow" typically refers to the local time) or on monotonic and steady timestamps with no particular epoch. The second is that the timestamp doesn't repeat but this can also happen with TAI, just that it can only happen with (a large amount of) clock synchronization; you should be prepared of wall clock timestamps repeating no matter it's UTC or TAI.

For those reasons I consider that using TAI primarily and UTC in display is not much superior to using UTC primarily. Not that I don't wish TAI to be universal, but given the current circumstances the switch doesn't justify its cost.

Re: Leap second hiatus

#80

Post by zokier »

bloak wrote: post #58
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.

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

You are asserting that without any justification. I see no benefits and lots of downsides in having leap seconds in civil time specifically.

Post reply on HN