If you're rolling your own datetime object for some reason, sure. But to the VAST majority of applications, this is an "update your referenced packages" change.
> What about all the embedded systems out there, which do very important things with timekeeping?
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.
Even if the customer themselves specified precisely how to handle the changeover once upon a time, they still get confused when it happens and the daily report has 23/25 hour entries, or the daily totaliser takes a mysterious 4% dip, or the date changes an hour earlier/later than expected etc.
I've never seen an embedded device with automatic changeover that didn't have some kind of configuration option to switch it off.
> 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.
The day that the time shift changes is constantly in flux, since the 1960s, before most embedded software was written. If you were writing embedded software that changes time zones automatically, unless you were very dumb, you made the date of the change configurable, given that we were on DST for a few years in a row in the early 70s.
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).
> 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 those systems are "very old" and still correct, then that means they are configurable. We changed the dates of start and end of daylight saving time in 2006.
Right it will be a pain to find them. But once you do it should just be a config change. The date of the DST changeover has changed a bunch of times, including being on DST for a few years straight in the 70s.
If it’s not already configurable then it had to be replaced in 2007 when we last changed the start of DST.
Well then to be fair you’d have had the same problem if they just changed the start date again. And the last time the start date was changed we only had 18 months to adjust.
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!
More than these exceptions, gadgets nowadays like to be IoT's and use internet time servers. The blast radius on things made since 2007 is likely smaller than you think.
It depends on what it asks for. If it asks for “current time in PDT” or “current time in PST” it just returns the same answer.
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.
Interesting, you're right. However does that not present a backdoor by setting up a local time server to proxy changes? It's a hack but ... a solution.
What's the difference between "Don't switch times and set the time correctly to the current DST" and "Don't switch times and set the time correctly the current standard time"?
Daylight savings rules change, somewhere around the world, several times a year.
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.
Sure, I know all about the joy of adjusting tz databases, etc.
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.
This might also affect northern non-tech businesses like ski resorts. They’ll either have to open an hour later (and possibly stay open an hour later), or install lighting.
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.
People deal with a random shift of light twice a year now, they cannot deal with no change? It's not like these decisions all need central planning and we must cover every edge case: people figure out what to do in a distributed way.
It's more complicated than that. Everything that calculates differences between two points in time for example would need to be updated to know about when the switch occurred. And more generally, this is an example of why it's complicated - because it's easy to overlook things that could be affected, so there's a great deal of investigation and testing that would need to be done.
Many systems that are in production have no regular release schedule, may go decades without any changes to code, and they have no maintainers.
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.
Sure the actual change might not sound super complicated, but hunting down all the little machines, services, and ancient code isn't easy for all organizations.
Most people don't that though. They use databases, system and apps that implement their own logic for time changes. Maybe you need an OS update. Maybe it's code that is controlled by a third party. There's plenty of logistics necessary to make sure things don't break when the DST rules change.
Yeah that's not gonna happen until October 2024. See GDPR as an example.
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.
