4 ms·

If you're rolling your own datetime object for some reason, sure. But to the VAST majority of applications, this is an "update your referenced packages" change.

gkoberger 5y ago
If you're a SaaS app, sure. You can't easily "npm update" an airplane, though. Like, if nothing else, think about all the plane tickets already sold for an hour that doesn't exist anymore.
- jaywalk 5y ago
  Airplanes receive software updates all the time.
  - sly010 5y ago
    Hopefully not via npm
    - jaywalk 5y ago
      You don't even want to see the node_modules folder on a Boeing 787.
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.
- 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.
ars 5y ago
A lot of systems only do major updates every two years. I guess you could push DST as a security update.

gkoberger 5y ago

If you're a SaaS app, sure. You can't easily "npm update" an airplane, though. Like, if nothing else, think about all the plane tickets already sold for an hour that doesn't exist anymore.

jaywalk 5y ago
Airplanes receive software updates all the time.
- sly010 5y ago
  Hopefully not via npm
  - jaywalk 5y ago
    You don't even want to see the node_modules folder on a Boeing 787.

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

ars 5y ago

A lot of systems only do major updates every two years. I guess you could push DST as a security update.