> 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-unanimousl...
Like, if nothing else, think about all the plane tickets already sold for an hour that doesn't exist anymore.
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.
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.
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.
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.
If it’s not already configurable then it had to be replaced in 2007 when we last changed the start of DST.
It's not.
> If it’s not already configurable then it had to be replaced in 2007 when we last changed the start of DST.
Yup, both these systems are about 10-15 years old.
It’s not like these changes are rare edge cases — it happens all the time.
So hopefully as you replace the system you find a vendor who writes good time code!
If it asks for UTC and does the conversion locally, then we’re back to the original problem of being able to update the switchover date which changes all the time and should be updateable.
So, the workaround is probably setting a lot of things to the "wrong" timezone one zone east, with daylight savings time off.
In turn, the logs will be lies, etc.
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.
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.
Yes, perfect, most developers start working on this Q1 or Q2 2024 at the earliest.
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.
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.
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.
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.
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.
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.
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.
I've worked on tzdata changes in the past and whether it's announced a month or a year in advance, progress is slow until the very last minute when teams can't put it off any longer. In other words, programmers are serial procrastinators and if you give them 2 years to prepare, they'll spend 1.9 doing nothing and scramble to fix everything in a month.
This might be the first big timestamp change in the US, but there have been a lot of changes like this in the rest of the world so any globally operating company has probably had to do this at least once already and should be well equipped to make this change on a faster timeline.
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.