5 ms·

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

> 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.
        pishpash 5y ago
        Interesting, you're right. However does that not present a backdoor by setting up a local time server to proxy changes? It's a hack but ... a solution.
        jedberg 5y ago
        It depends on what it asks for. If it asks for “current time in PDT” or “current time in PST” it just returns the same answer. If it asks for UTC and does the conversion locally, then we’re back to the original problem of being able to update the switchover date which changes all the time and should be updateable.
- 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.

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.
        pishpash 5y ago
        Interesting, you're right. However does that not present a backdoor by setting up a local time server to proxy changes? It's a hack but ... a solution.
        jedberg 5y ago
        It depends on what it asks for. If it asks for “current time in PDT” or “current time in PST” it just returns the same answer. If it asks for UTC and does the conversion locally, then we’re back to the original problem of being able to update the switchover date which changes all the time and should be updateable.
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.