3 ms·

We make small semi-regular changes to timezones all the time. DST switches, governments arbitrarily deciding that their country is going yo be in a different ti

We make small semi-regular changes to timezones all the time. DST switches, governments arbitrarily deciding that their country is going yo be in a different timezone (at a 2 day notice), or move the DST switch day by 2 weeks, etc etc. This is a solved problem and it happens all the time. The systems and datastructures that can deal with this (eg tzdata and the process & people behind it) are already in place.

throw0101c 2y ago
> This is a solved problem and it happens all the time. UTC changing does not happen all the time: what the 'all the time' thing is a display/UI offeset against UTC. Time itself is not changed in those situations, but would be with a 'UTC jump'. The closest thing we get to universal time 'changing' are leap years and February 29, and we regularly get stories about people messing that up. And if something as common and regular as that gets fumbled I have little hope for pulling off a one-off jump of UTC. It is coördinating the universal part that I would imagine to be the difficult part.
- skrebbel 2y ago
  Then just keep UTC when it is? (ie allow its prime meridian to shift away from Greenwich) Adjust all the timezones by half an hour in a few millennia. It’s really both fine and up to our grand-grand-grand-grand-etc-children to decide. Really, this is a non-problem.
  - organsnyder 2y ago
    > It’s really both fine and up to our grand-grand-grand-grand-etc-children to decide. I'd rather build gradual adjustments into our systems so that they have to be resilient to this sort of thing. Sure, leaving it up to our distant descendants is enticing, but then they're going to have a Y2K-sized problem to fix. I'd rather leave a legacy of systems that were designed to be resilient.
    - School-Cotton 2y ago
      > then they're going to have a Y2K-sized problem to fix. No they aren't. tzdb updates happen several times a year already, and you don't notice.
      - organsnyder 2y ago
        The suggestion I was responding to was to basically stop doing this.
        School-Cotton 2y ago
        I thought it was suggesting exactly the opposite: that we handle this with tzdb updates, not leap seconds.
        skrebbel 2y ago
        Yep! (assuming our grand-grand-grand-grand-etc-children still have something like a tzdb)
        deleted 2y ago
        [deleted]
  - pixl97 2y ago
    This really doesn't solve anything either. Attempting to treat time as something that ticks towards the future at a consistent rate relative to all observers is already broken. The Earths rotation is slowing down over geologic time. Even on short orders things like earthquakes can change rate of rotation of the planet. Start putting stuff on spaceships and different planets and you start seeing how wibbily wobbily time really is. Just like we have to focus on making application secure, we need to ensure our applications don't shit their pants when applications change time in unexpected ways.
- afiori 2y ago
  The universal part is alread coordinated, the problem is that it keeps adding and removing seconds with no regularity and little advance notice.

throw0101c 2y ago

> This is a solved problem and it happens all the time. UTC changing does not happen all the time: what the 'all the time' thing is a display/UI offeset against UTC. Time itself is not changed in those situations, but would be with a 'UTC jump'. The closest thing we get to universal time 'changing' are leap years and February 29, and we regularly get stories about people messing that up. And if something as common and regular as that gets fumbled I have little hope for pulling off a one-off jump of UTC. It is coördinating the universal part that I would imagine to be the difficult part.

skrebbel 2y ago
Then just keep UTC when it is? (ie allow its prime meridian to shift away from Greenwich) Adjust all the timezones by half an hour in a few millennia. It’s really both fine and up to our grand-grand-grand-grand-etc-children to decide. Really, this is a non-problem.
- organsnyder 2y ago
  > It’s really both fine and up to our grand-grand-grand-grand-etc-children to decide. I'd rather build gradual adjustments into our systems so that they have to be resilient to this sort of thing. Sure, leaving it up to our distant descendants is enticing, but then they're going to have a Y2K-sized problem to fix. I'd rather leave a legacy of systems that were designed to be resilient.
  - School-Cotton 2y ago
    > then they're going to have a Y2K-sized problem to fix. No they aren't. tzdb updates happen several times a year already, and you don't notice.
    - organsnyder 2y ago
      The suggestion I was responding to was to basically stop doing this.
      - School-Cotton 2y ago
        I thought it was suggesting exactly the opposite: that we handle this with tzdb updates, not leap seconds.
        skrebbel 2y ago
        Yep! (assuming our grand-grand-grand-grand-etc-children still have something like a tzdb)
      - deleted 2y ago
        [deleted]
- pixl97 2y ago
  This really doesn't solve anything either. Attempting to treat time as something that ticks towards the future at a consistent rate relative to all observers is already broken. The Earths rotation is slowing down over geologic time. Even on short orders things like earthquakes can change rate of rotation of the planet. Start putting stuff on spaceships and different planets and you start seeing how wibbily wobbily time really is. Just like we have to focus on making application secure, we need to ensure our applications don't shit their pants when applications change time in unexpected ways.
afiori 2y ago
The universal part is alread coordinated, the problem is that it keeps adding and removing seconds with no regularity and little advance notice.