4 ms·

> 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

> 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

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