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.
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.
Yes, perfect, most developers start working on this Q1 or Q2 2024 at the earliest.