8 ms·

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 o

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.

lifthrasiir 6y ago
> 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.
- wyattpeak 6y ago
  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.
  - lifthrasiir 6y ago
    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.
    - wyattpeak 6y ago
      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.
      - lifthrasiir 6y ago
        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 https://qntm.org/abolish
      - zokier 6y ago
        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.
kungito 6y ago
I don't see a single thing different between leap hour and DST switch. Especially since Europe wants to cancel DST it wont even be something which happens periodically forever
endymi0n 6y ago
"If it hurts, do it more often" — Martin Fowler
- throw0101a 6y ago
  Practice makes perfect. Release early, release often.
zokier 6y ago
> 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.
zokier 6y ago
> 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.
- Jestar342 6y ago
  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.
- fanf2 6y ago
  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 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 https://www.ucolick.org/~sla/leapsecs/dutc.html
- deleted 6y ago
  [deleted]
- wyattpeak 6y ago
  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.

lifthrasiir 6y ago

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

wyattpeak 6y ago
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.
- lifthrasiir 6y ago
  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.
  - wyattpeak 6y ago
    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.
    - lifthrasiir 6y ago
      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 https://qntm.org/abolish
    - zokier 6y ago
      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.

kungito 6y ago

I don't see a single thing different between leap hour and DST switch. Especially since Europe wants to cancel DST it wont even be something which happens periodically forever

endymi0n 6y ago

"If it hurts, do it more often" — Martin Fowler

throw0101a 6y ago
Practice makes perfect. Release early, release often.

zokier 6y ago

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

zokier 6y ago

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

Jestar342 6y ago
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.
fanf2 6y ago
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 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 https://www.ucolick.org/~sla/leapsecs/dutc.html
deleted 6y ago
[deleted]
wyattpeak 6y ago
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.