3 ms·

What about all the embedded systems out there, which do very important things with timekeeping? What about all the existing appointments, etc. IMO 2024 -- 2 y

by mlyle 5y ago

What about all the embedded systems out there, which do very important things with timekeeping? What about all the existing appointments, etc. IMO 2024 -- 2 years-- is just the perfect amount of time. It's slightly aggressive but doable. If people frequently make appointments, buy tickets, etc, for a year out, that leaves a year to get most of the software world cut over.

munch117 5y ago
> What about all the embedded systems out there, which do very important things with timekeeping? I've written a few of those. Supporting not-DST basically comes down to unchecking the bit in the configuration where it says: [ ] Confuse the hell out of the users twice a year. Even if the customer themselves specified precisely how to handle the changeover once upon a time, they still get confused when it happens and the daily report has 23/25 hour entries, or the daily totaliser takes a mysterious 4% dip, or the date changes an hour earlier/later than expected etc. I've never seen an embedded device with automatic changeover that didn't have some kind of configuration option to switch it off.
- mlyle 5y ago
  > I've never seen an embedded device with automatic changeover that didn't have some kind of configuration option to switch it off. "Always in Daylight savings time" tends not to be the option that's offered-- either always in the standard zone or always changing. And, the point isn't that devices can be reprogrammed or reconfigured: it's that there's a lot of them, with uneven levels of support, and difficult to go reach them all.
  - jedberg 5y ago
    The day that the time shift changes is constantly in flux, since the 1960s, before most embedded software was written. If you were writing embedded software that changes time zones automatically, unless you were very dumb, you made the date of the change configurable, given that we were on DST for a few years in a row in the early 70s. So yes it's a lot of work to find them all, but they should all be configurable to just set the next Standard Time shift to be the max(datetime).
    - mlyle 5y ago
      > So yes it's a lot of work to find them all, but they should all be configurable to just set the next Standard Time shift to be the max(datetime). The two systems at my school where time is important are old and are not likely to work correctly with current firmware, and it's unclear whether new firmware will be available: - Our PA/bell system - Our automatic gate opener At my home, most things are smaller problems (I doubt the prosumer switches, etc, that I have can handle it or will be updated, but I set them to UTC) or cloud services that are likely to update. I do have a few old GPS things whose handling of localtime will probably be screwed up forever, too. That's just off the top of my head. It'll be a big pain in the ass.
      - jedberg 5y ago
        Right it will be a pain to find them. But once you do it should just be a config change. The date of the DST changeover has changed a bunch of times, including being on DST for a few years straight in the 70s. If it’s not already configurable then it had to be replaced in 2007 when we last changed the start of DST.
        mlyle 5y ago
        > If it’s not already configurable It's not. > If it’s not already configurable then it had to be replaced in 2007 when we last changed the start of DST. Yup, both these systems are about 10-15 years old.
        pishpash 5y ago
        More than these exceptions, gadgets nowadays like to be IoT's and use internet time servers. The blast radius on things made since 2007 is likely smaller than you think.
        mlyle 5y ago
        Using internet time servers is largely the problem, because then you need to take UTC and make it into a useful local zone.
  - parineum 5y ago
    What's the difference between "Don't switch times and set the time correctly to the current DST" and "Don't switch times and set the time correctly the current standard time"?
    - mlyle 5y ago
      The choice is often one of 4 named timezones for NA (with hardcoded offsets to UTC) and "Automatically Do Daylight Savings Time" on or off. So, the workaround is probably setting a lot of things to the "wrong" timezone one zone east, with daylight savings time off. In turn, the logs will be lies, etc.
  - munch117 5y ago
    "Always in Daylight savings time" is just a different time zone. Doesn't need a setting of its own.
michaelt 5y ago
Daylight savings rules change, somewhere around the world, several times a year. For example, between 2011 and 2016 Istanbul changed their DST rules 7 times [1]. So I think you'll find a great many systems already have a way of distributing DST rule updates. [1] https://github.com/eggert/tz/blob/main/europe#L4014 https://github.com/eggert/tz/blob/main/europe#L4014
- mlyle 5y ago
  Sure, I know all about the joy of adjusting tz databases, etc. There are a whole lot of things here in the US that have basically never required these updates. And, well, there's all the problems where people have assumed timezones won't change, and e.g. have stored timestamps of future events in UTC in databases that really semantically are supposed to be at 9AM in a given timezone.
ihateolives 5y ago
> IMO 2024 -- 2 years-- is just the perfect amount of time. It's slightly aggressive but doable. Yes, perfect, most developers start working on this Q1 or Q2 2024 at the earliest.
ryanmercer 5y ago
>What about all the embedded systems out there, We didn't observe daylight savings here in Indiana until about a decade and a half ago, and we have our own time zone in everything still (go look, you'll find "Indiana (East)" or some such). I can't imagine it'd be too difficult to implement.

by mlyle 5y ago

munch117 5y ago

> What about all the embedded systems out there, which do very important things with timekeeping? I've written a few of those. Supporting not-DST basically comes down to unchecking the bit in the configuration where it says: [ ] Confuse the hell out of the users twice a year. Even if the customer themselves specified precisely how to handle the changeover once upon a time, they still get confused when it happens and the daily report has 23/25 hour entries, or the daily totaliser takes a mysterious 4% dip, or the date changes an hour earlier/later than expected etc. I've never seen an embedded device with automatic changeover that didn't have some kind of configuration option to switch it off.

mlyle 5y ago
> I've never seen an embedded device with automatic changeover that didn't have some kind of configuration option to switch it off. "Always in Daylight savings time" tends not to be the option that's offered-- either always in the standard zone or always changing. And, the point isn't that devices can be reprogrammed or reconfigured: it's that there's a lot of them, with uneven levels of support, and difficult to go reach them all.
- jedberg 5y ago
  The day that the time shift changes is constantly in flux, since the 1960s, before most embedded software was written. If you were writing embedded software that changes time zones automatically, unless you were very dumb, you made the date of the change configurable, given that we were on DST for a few years in a row in the early 70s. So yes it's a lot of work to find them all, but they should all be configurable to just set the next Standard Time shift to be the max(datetime).
  - mlyle 5y ago
    > So yes it's a lot of work to find them all, but they should all be configurable to just set the next Standard Time shift to be the max(datetime). The two systems at my school where time is important are old and are not likely to work correctly with current firmware, and it's unclear whether new firmware will be available: - Our PA/bell system - Our automatic gate opener At my home, most things are smaller problems (I doubt the prosumer switches, etc, that I have can handle it or will be updated, but I set them to UTC) or cloud services that are likely to update. I do have a few old GPS things whose handling of localtime will probably be screwed up forever, too. That's just off the top of my head. It'll be a big pain in the ass.
    - jedberg 5y ago
      Right it will be a pain to find them. But once you do it should just be a config change. The date of the DST changeover has changed a bunch of times, including being on DST for a few years straight in the 70s. If it’s not already configurable then it had to be replaced in 2007 when we last changed the start of DST.
      - mlyle 5y ago
        > If it’s not already configurable It's not. > If it’s not already configurable then it had to be replaced in 2007 when we last changed the start of DST. Yup, both these systems are about 10-15 years old.
        pishpash 5y ago
        More than these exceptions, gadgets nowadays like to be IoT's and use internet time servers. The blast radius on things made since 2007 is likely smaller than you think.
        mlyle 5y ago
        Using internet time servers is largely the problem, because then you need to take UTC and make it into a useful local zone.
- parineum 5y ago
  What's the difference between "Don't switch times and set the time correctly to the current DST" and "Don't switch times and set the time correctly the current standard time"?
  - mlyle 5y ago
    The choice is often one of 4 named timezones for NA (with hardcoded offsets to UTC) and "Automatically Do Daylight Savings Time" on or off. So, the workaround is probably setting a lot of things to the "wrong" timezone one zone east, with daylight savings time off. In turn, the logs will be lies, etc.
- munch117 5y ago
  "Always in Daylight savings time" is just a different time zone. Doesn't need a setting of its own.

michaelt 5y ago

Daylight savings rules change, somewhere around the world, several times a year. For example, between 2011 and 2016 Istanbul changed their DST rules 7 times [1]. So I think you'll find a great many systems already have a way of distributing DST rule updates. [1] https://github.com/eggert/tz/blob/main/europe#L4014 https://github.com/eggert/tz/blob/main/europe#L4014

mlyle 5y ago
Sure, I know all about the joy of adjusting tz databases, etc. There are a whole lot of things here in the US that have basically never required these updates. And, well, there's all the problems where people have assumed timezones won't change, and e.g. have stored timestamps of future events in UTC in databases that really semantically are supposed to be at 9AM in a given timezone.

ihateolives 5y ago

> IMO 2024 -- 2 years-- is just the perfect amount of time. It's slightly aggressive but doable. Yes, perfect, most developers start working on this Q1 or Q2 2024 at the earliest.

ryanmercer 5y ago

>What about all the embedded systems out there, We didn't observe daylight savings here in Indiana until about a decade and a half ago, and we have our own time zone in everything still (go look, you'll find "Indiana (East)" or some such). I can't imagine it'd be too difficult to implement.