3 ms·

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

> 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.
  - _greim_ 5y ago
    Thanks for this answer. > Solaris Haha, I worked at Sun at the time and definitely remember some of my coworkers grumbling about it.
  - Dylan16807 5y ago
    One reboot during a seven month window doesn't sound too bad either.
    - throw0101a 5y ago
      > One reboot during a seven month window doesn't sound too bad either. It is on 24/7 systems that had no budget for HA, especially if you had several hundred/thousand systems and things like Ansible and Chef weren't invented yet. CFEngine was the big boy in town and Puppet was an up-and-comer. (Remember this was the 2000s). * https://en.wikipedia.org/wiki/Infrastructure_as_code https://en.wikipedia.org/wiki/Infrastructure_as_code
jsmith45 5y ago
The last DST change gave about a year and a half notice. This also gives a year and a half notice. But that is a super, super weird date given that it means we would set the clocks back, and then set them forward again about 2 weeks later.

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.
- _greim_ 5y ago
  Thanks for this answer. > Solaris Haha, I worked at Sun at the time and definitely remember some of my coworkers grumbling about it.
- Dylan16807 5y ago
  One reboot during a seven month window doesn't sound too bad either.
  - throw0101a 5y ago
    > One reboot during a seven month window doesn't sound too bad either. It is on 24/7 systems that had no budget for HA, especially if you had several hundred/thousand systems and things like Ansible and Chef weren't invented yet. CFEngine was the big boy in town and Puppet was an up-and-comer. (Remember this was the 2000s). * https://en.wikipedia.org/wiki/Infrastructure_as_code https://en.wikipedia.org/wiki/Infrastructure_as_code

jsmith45 5y ago

The last DST change gave about a year and a half notice. This also gives a year and a half notice. But that is a super, super weird date given that it means we would set the clocks back, and then set them forward again about 2 weeks later.