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.
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.
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-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.
> Solaris
Haha, I worked at Sun at the time and definitely remember some of my coworkers grumbling about it.
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).
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.