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