5 ms·

The Hill article[1] says it won't go into effect until November 20, 2023. > The proposal would not take effect until Nov. 20, 2023, to give airlines and other

The Hill article[1] says it won't go into effect until November 20, 2023. > The proposal would not take effect until Nov. 20, 2023, to give airlines and other transportation industries more time to adjust to the change. But we switch back to standard time on November 5, 2023. Just to get two weeks of that until we switch back to summer time permanently? [1] https://thehill.com/homenews/senate/598314-senate-unanimously-approves-making-daylight-saving-time-permanent https://thehill.com/homenews/senate/598314-senate-unanimousl...

MontagFTB 5y ago
This made me laugh out loud.
singlow 5y ago
After that date we would no longer transition away from daylight saving time. It would not cause an immediate transition. There would be one more transition in the following year to get back onto daylight saving time. So the effective effective date is really march of 2024.
- metadat 5y ago
  It's so stupid to delay for years, this should take effect immediately. There is no real sense in pussy footing about, people need to just do the work either way.
  - bootlooped 5y ago
    Think of all the code that needs changed. I can wait another year or two, just as long as we actually commit and follow through.
    - parineum 5y ago
      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.
    - r00fus 5y ago
      Are you serious? The code would be to simply not change time zones 2 times a year. Sure needs testing but should be an elegant simple change.
      - gen3 5y ago
        Sure the actual change might not sound super complicated, but hunting down all the little machines, services, and ancient code isn't easy for all organizations.
      - tempestn 5y ago
        It's more complicated than that. Everything that calculates differences between two points in time for example would need to be updated to know about when the switch occurred. And more generally, this is an example of why it's complicated - because it's easy to overlook things that could be affected, so there's a great deal of investigation and testing that would need to be done.
      - dudus 5y ago
        Most people don't that though. They use databases, system and apps that implement their own logic for time changes. Maybe you need an OS update. Maybe it's code that is controlled by a third party. There's plenty of logistics necessary to make sure things don't break when the DST rules change.
      - kube-system 5y ago
        Many systems that are in production have no regular release schedule, may go decades without any changes to code, and they have no maintainers. The delay is for those cases -- where someone may need to be hired to fix it, or an entire system may need to be replaced if it is no longer maintainable.
    - pishpash 5y ago
      That's badly written code. Timezones (globally) changed over time. Even Bush Jr. changed DST.
    - awb 5y ago
      This might also affect northern non-tech businesses like ski resorts. They’ll either have to open an hour later (and possibly stay open an hour later), or install lighting. It might also affect things like outdoor after-school activities that will now have enough light to be held during winter, which in Northern California potentially means extending or shifting the soccer season.
      - pishpash 5y ago
        People deal with a random shift of light twice a year now, they cannot deal with no change? It's not like these decisions all need central planning and we must cover every edge case: people figure out what to do in a distributed way.
    - fy20 5y ago
      Yeah that's not gonna happen until October 2024. See GDPR as an example. The regulations were adopted in April 2016, but they didn't become enforceable until May 2018. Most companies didn't even start thinking about it until March 2018 or later. The first fine was handed out in May 2019.
  - cbhl 5y ago
    A few years' delay would be comparable to the DST changes made in 2005 (which went into effect in 2007 -- they extended DST in the US by a month on each end; moving it from Apr-Oct to Mar-Nov).
  - wyldfire 5y ago
    if it took effect too quickly, you would frequently find yourself second guessing that computerized system telling you when to be somewhere. "Oh that's right, Delta airlines hasn't switched yet but Southwest and Lufthansa have. Oh well, I'll catch the next flight." Just think of all the phones whose software updates have recently expired. No one catches on right away that their security updates stopped rolling in. But they'll definitely notice when their phone stops matching the time that they talk about on the radio.
- withzombies 5y ago
  Hah, thanks for pointing that out. The articles on it really should say when permanent daylight time would start, not when the bill would take effect.
- azinman2 5y ago
  Dunning–Kruger effect is very real. There so many systems affected by this on all kinds of timelines and life support that such a change would be catastrophic. Just because it may seem simple to you doesn’t mean it actually is.
  - nulbyte 5y ago
    Other countries have made these changes on shorter time frames in recent memory. I don't recall hearing about any catastrophes. In 2011, Samoa changed time zones to land on the other side of the international date line. I don't believe that was years in the making. Even last year, they announced they would no longer observe daylight saving time; they decided that 11 days before they were scheduled to switch their clocks. In January of 2015, Chile announced they would keep daylight saving time year-round when they rolled forward in April. Then in 2016, they scrapped that. In 2019, they even changed the dates on which daylight saving started and ended. While this was over the course of several years, they didn't go into this thinking about how to make it complicated for the next four years. Many of the states don't seem to think this is a serious concern, either. Several, including my own (Kentucky) passed legislation to permanently observe daylight saving as soon as Congress would allow it. I don't think the folks considering these measures are underestimating our ability to deal with these types of changes.
    - NateEag 5y ago
      https://codeofmatt.com/on-the-timing-of-time-zone-changes/ https://codeofmatt.com/on-the-timing-of-time-zone-changes/
    - jsmith45 5y ago
      The late changes to daylight saving time rules pretty much always mean that for several days to potentially over a month, users will be encountering systems with the incorrect time. Often times they will try to "correct it" by manually changing the system time but then time sync services might undo that, and if not, then once the time zone package finally makes it to the system, it "breaks" again, because the user should not have messed with the clocks in the first place. The authors of the time zone database strongly encourage long notice periods for changes, as there are plenty of programs that use this data that have a month or more of delay between when an updated database is published, and when end devices will realistically get the update. And that is for people who don't habitually put off updates! When DST rules were last change we had about a year and a half notice, which is realistically what this bill also provides.
- hathawsh 5y ago
  That also means existing software/firmware will continue to use correct TZ offsets until November 2024, so that's the deadline for updates.
  - singlow 5y ago
    I would say the deadline is much sooner, since it becomes very necessary for some software to correctly recognize future dates correctly well before they arrive.
mdturnerphys 5y ago
The bill doesn't appear to have an effective date: https://www.congress.gov/bill/117th-congress/senate-bill/623/text?r=1&s=2 https://www.congress.gov/bill/117th-congress/senate-bill/623...
- gbear605 5y ago
  There was an amendment adopted to set the effective date to Nov 2023, it just doesn’t display on Congress’ website (yet).
throw0101a 5y ago
> The Hill article[1] says it won't go into effect until November 20, 2023. Way too soon. Stupidly so IMHO. I went through the last DST law change, and it took quite a lot of work in many IT areas. Unixes weren't too bad, but there was all the JREs, databases, etc. And that's not getting into all the embedded and industrial gadgets.
- stuff4ben 5y ago
  Repeat after me, "job security". I just hope we still have some 32-bit machines running in 2038 so that after I've conveniently retired, I can be called back in to consult.
  - throw0101a 5y ago
    No thanks. My job security is being competent. The less drama I have the better I'm doing my job.
    - shaoonb 5y ago
      Know anyone who ended up rich thanks to Y2K? Possibly not since chances are they went into early retirement.
- _greim_ 5y ago
  > I went through the last DST law change I'd be curious to know, to what extent did that change prepare the world for this change? Was it more common to adapt IT systems to be more flexible, or to do minimal work to change hard-coded values? I imagine it was a mix but the pessimist in me thinks overwhelmingly the latter.
  - throw0101a 5y ago
    Yes, there were a lot of changes, especially given the concentration of software development in the US. At the time I was dealing with Solaris a lot, and previously you had to reboot the system for things to become permanent, but there was a tweak made where the system started to stat() the file /etc/localtime to see if it changed, and reload it if it did. So new process would get the new tzdata bits. The JRE/JDK has a separate tzdata updater: * https://www.oracle.com/java/technologies/javase/tzupdater-readme.html https://www.oracle.com/java/technologies/javase/tzupdater-re... So it may not as bad as it was in the past. Previous the US tzdata bits hadn't change in several decades, over the course of the 1980s and 1990s, when basically the entire computer industry mainstreamed. So things may not be as bad as last time—but I'd still prefer a little extra time.

MontagFTB 5y ago

This made me laugh out loud.

singlow 5y ago

After that date we would no longer transition away from daylight saving time. It would not cause an immediate transition. There would be one more transition in the following year to get back onto daylight saving time. So the effective effective date is really march of 2024.

metadat 5y ago
It's so stupid to delay for years, this should take effect immediately. There is no real sense in pussy footing about, people need to just do the work either way.
- bootlooped 5y ago
  Think of all the code that needs changed. I can wait another year or two, just as long as we actually commit and follow through.
  - parineum 5y ago
    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.
  - r00fus 5y ago
    Are you serious? The code would be to simply not change time zones 2 times a year. Sure needs testing but should be an elegant simple change.
    - gen3 5y ago
      Sure the actual change might not sound super complicated, but hunting down all the little machines, services, and ancient code isn't easy for all organizations.
    - tempestn 5y ago
      It's more complicated than that. Everything that calculates differences between two points in time for example would need to be updated to know about when the switch occurred. And more generally, this is an example of why it's complicated - because it's easy to overlook things that could be affected, so there's a great deal of investigation and testing that would need to be done.
    - dudus 5y ago
      Most people don't that though. They use databases, system and apps that implement their own logic for time changes. Maybe you need an OS update. Maybe it's code that is controlled by a third party. There's plenty of logistics necessary to make sure things don't break when the DST rules change.
    - kube-system 5y ago
      Many systems that are in production have no regular release schedule, may go decades without any changes to code, and they have no maintainers. The delay is for those cases -- where someone may need to be hired to fix it, or an entire system may need to be replaced if it is no longer maintainable.
  - pishpash 5y ago
    That's badly written code. Timezones (globally) changed over time. Even Bush Jr. changed DST.
  - awb 5y ago
    This might also affect northern non-tech businesses like ski resorts. They’ll either have to open an hour later (and possibly stay open an hour later), or install lighting. It might also affect things like outdoor after-school activities that will now have enough light to be held during winter, which in Northern California potentially means extending or shifting the soccer season.
    - pishpash 5y ago
      People deal with a random shift of light twice a year now, they cannot deal with no change? It's not like these decisions all need central planning and we must cover every edge case: people figure out what to do in a distributed way.
  - fy20 5y ago
    Yeah that's not gonna happen until October 2024. See GDPR as an example. The regulations were adopted in April 2016, but they didn't become enforceable until May 2018. Most companies didn't even start thinking about it until March 2018 or later. The first fine was handed out in May 2019.
- cbhl 5y ago
  A few years' delay would be comparable to the DST changes made in 2005 (which went into effect in 2007 -- they extended DST in the US by a month on each end; moving it from Apr-Oct to Mar-Nov).
- wyldfire 5y ago
  if it took effect too quickly, you would frequently find yourself second guessing that computerized system telling you when to be somewhere. "Oh that's right, Delta airlines hasn't switched yet but Southwest and Lufthansa have. Oh well, I'll catch the next flight." Just think of all the phones whose software updates have recently expired. No one catches on right away that their security updates stopped rolling in. But they'll definitely notice when their phone stops matching the time that they talk about on the radio.
withzombies 5y ago
Hah, thanks for pointing that out. The articles on it really should say when permanent daylight time would start, not when the bill would take effect.
azinman2 5y ago
Dunning–Kruger effect is very real. There so many systems affected by this on all kinds of timelines and life support that such a change would be catastrophic. Just because it may seem simple to you doesn’t mean it actually is.
- nulbyte 5y ago
  Other countries have made these changes on shorter time frames in recent memory. I don't recall hearing about any catastrophes. In 2011, Samoa changed time zones to land on the other side of the international date line. I don't believe that was years in the making. Even last year, they announced they would no longer observe daylight saving time; they decided that 11 days before they were scheduled to switch their clocks. In January of 2015, Chile announced they would keep daylight saving time year-round when they rolled forward in April. Then in 2016, they scrapped that. In 2019, they even changed the dates on which daylight saving started and ended. While this was over the course of several years, they didn't go into this thinking about how to make it complicated for the next four years. Many of the states don't seem to think this is a serious concern, either. Several, including my own (Kentucky) passed legislation to permanently observe daylight saving as soon as Congress would allow it. I don't think the folks considering these measures are underestimating our ability to deal with these types of changes.
  - NateEag 5y ago
    https://codeofmatt.com/on-the-timing-of-time-zone-changes/ https://codeofmatt.com/on-the-timing-of-time-zone-changes/
  - jsmith45 5y ago
    The late changes to daylight saving time rules pretty much always mean that for several days to potentially over a month, users will be encountering systems with the incorrect time. Often times they will try to "correct it" by manually changing the system time but then time sync services might undo that, and if not, then once the time zone package finally makes it to the system, it "breaks" again, because the user should not have messed with the clocks in the first place. The authors of the time zone database strongly encourage long notice periods for changes, as there are plenty of programs that use this data that have a month or more of delay between when an updated database is published, and when end devices will realistically get the update. And that is for people who don't habitually put off updates! When DST rules were last change we had about a year and a half notice, which is realistically what this bill also provides.
hathawsh 5y ago
That also means existing software/firmware will continue to use correct TZ offsets until November 2024, so that's the deadline for updates.
- singlow 5y ago
  I would say the deadline is much sooner, since it becomes very necessary for some software to correctly recognize future dates correctly well before they arrive.

mdturnerphys 5y ago

The bill doesn't appear to have an effective date: https://www.congress.gov/bill/117th-congress/senate-bill/623/text?r=1&s=2 https://www.congress.gov/bill/117th-congress/senate-bill/623...

gbear605 5y ago
There was an amendment adopted to set the effective date to Nov 2023, it just doesn’t display on Congress’ website (yet).

throw0101a 5y ago

> The Hill article[1] says it won't go into effect until November 20, 2023. Way too soon. Stupidly so IMHO. I went through the last DST law change, and it took quite a lot of work in many IT areas. Unixes weren't too bad, but there was all the JREs, databases, etc. And that's not getting into all the embedded and industrial gadgets.

stuff4ben 5y ago
Repeat after me, "job security". I just hope we still have some 32-bit machines running in 2038 so that after I've conveniently retired, I can be called back in to consult.
- throw0101a 5y ago
  No thanks. My job security is being competent. The less drama I have the better I'm doing my job.
  - shaoonb 5y ago
    Know anyone who ended up rich thanks to Y2K? Possibly not since chances are they went into early retirement.
_greim_ 5y ago
> I went through the last DST law change I'd be curious to know, to what extent did that change prepare the world for this change? Was it more common to adapt IT systems to be more flexible, or to do minimal work to change hard-coded values? I imagine it was a mix but the pessimist in me thinks overwhelmingly the latter.
- throw0101a 5y ago
  Yes, there were a lot of changes, especially given the concentration of software development in the US. At the time I was dealing with Solaris a lot, and previously you had to reboot the system for things to become permanent, but there was a tweak made where the system started to stat() the file /etc/localtime to see if it changed, and reload it if it did. So new process would get the new tzdata bits. The JRE/JDK has a separate tzdata updater: * https://www.oracle.com/java/technologies/javase/tzupdater-readme.html https://www.oracle.com/java/technologies/javase/tzupdater-re... So it may not as bad as it was in the past. Previous the US tzdata bits hadn't change in several decades, over the course of the 1980s and 1990s, when basically the entire computer industry mainstreamed. So things may not be as bad as last time—but I'd still prefer a little extra time.