4 ms·

> That doesn't feel like something that NEEDS sub-second precision. It does not need to be sub-second, but sub-seconds add up over time. The Julian calendar w

> That doesn't feel like something that NEEDS sub-second precision. It does not need to be sub-second, but sub-seconds add up over time. The Julian calendar wasn't that far off, but it was cumulative, so to fix things it took a ten day jump: * https://en.wikipedia.org/wiki/Gregorian_calendar https://en.wikipedia.org/wiki/Gregorian_calendar It is considered easier to have a few small(er) semi-regular jumps than suddenly having to making giant, sudden, one-off jump in the future.

skrebbel 2y ago
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.
School-Cotton 2y ago
It feels like you missed the main point. Time-zone changes are already very easy to handle and are sufficient for dealing with this problem without having to use a leap second or leap minute ever.
- throw0101c 2y ago
  > Time-zone changes are already very easy to handle and are sufficient for dealing with this problem without having to use a leap second or leap minute ever. TZ changes are a display delta against UTC. 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. If something as common as February 29 is fumbled, what are the odds of pulling a one-off event? And as someone who was a sysadmin when the US changed its TZ rules many moons ago, the sudden rule change was anything but straight-forward given the fairly static nature that they had been for the long history of software development that had occurred until that point: a lot of software is US-developed, and there was little/zero consideration to updating rules. (Though I think that event caused a lot of developers to be more understanding.)
  - afiori 2y ago
    In 400 years we can define new 30 minutes shifted timezones and in 400 - 500 years governments can slowly change their official timezones (maybe at summer/winter time they shift 30 minutes instead of 60). It does not feel like a big issue.
  - School-Cotton 2y ago
    The point is we don't need to change universal time. Thousands of years from now, when solar time drifts away from UTC enough for a particular country to care, that country can change its time zone. There doesn't need to be any global coordination and the process will be gradual enough that nobody will notice.
    - layer8 2y ago
      The EU already fails to agree on dropping DST (and adjusting time zones in the process), because member states will be affected differently, and neighboring countries that should really be in different time zones benefit from being in the same zone. I doubt they could agree on shifting their time zones, because invariably some countries would get the short stick.

skrebbel 2y ago

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.

School-Cotton 2y ago

It feels like you missed the main point. Time-zone changes are already very easy to handle and are sufficient for dealing with this problem without having to use a leap second or leap minute ever.

throw0101c 2y ago
> Time-zone changes are already very easy to handle and are sufficient for dealing with this problem without having to use a leap second or leap minute ever. TZ changes are a display delta against UTC. 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. If something as common as February 29 is fumbled, what are the odds of pulling a one-off event? And as someone who was a sysadmin when the US changed its TZ rules many moons ago, the sudden rule change was anything but straight-forward given the fairly static nature that they had been for the long history of software development that had occurred until that point: a lot of software is US-developed, and there was little/zero consideration to updating rules. (Though I think that event caused a lot of developers to be more understanding.)
- afiori 2y ago
  In 400 years we can define new 30 minutes shifted timezones and in 400 - 500 years governments can slowly change their official timezones (maybe at summer/winter time they shift 30 minutes instead of 60). It does not feel like a big issue.
- School-Cotton 2y ago
  The point is we don't need to change universal time. Thousands of years from now, when solar time drifts away from UTC enough for a particular country to care, that country can change its time zone. There doesn't need to be any global coordination and the process will be gradual enough that nobody will notice.
  - layer8 2y ago
    The EU already fails to agree on dropping DST (and adjusting time zones in the process), because member states will be affected differently, and neighboring countries that should really be in different time zones benefit from being in the same zone. I doubt they could agree on shifting their time zones, because invariably some countries would get the short stick.