These systems can handle updates, yes, but my gut feeling says it's likely that not many admins realize that these kinds of components also require updates, leading to apps that use such software playing by outdated DST rules should a change occur, even if the underlying OS was patched. I think most presume that the system TZ database facilities and functions are used. ISTR seeing a little of this when the US changed its DST observance in 2005.
All this foo about DST in the US has me thinking that we're all debating/arguing about what amounts to a kludge applied to the human construct of timezones. It's a handy kludge in some respects and inconvenient in others. But removing DST changes altogether ignores the very real physicality of seasonal variations in how long that ball of plasma hovers above the local horizon... and that "local" bit is the key that I don't think many understand. The linked article makes a neat but I think somewhat flaccid attempt to drive that home. I wonder if anyone has done a study regarding DST across the US and, critically, across all latitudes. I'm pretty certain the most vehement distaste for DST would be found in the lower states, mixed in the middle, and either pro-DST or at least ambivalent in the most northern states. I live at 39*N and, while I find the DST clock shift inconvenient for a day, it's useful for the season, but not strongly. I often spend time at 20*N during both summer and winter solstices and DST would be plainly unnecessary there. So this leads me to wonder if our single-dimension timezones, roughly organized along a mishmash of longitude and political boundaries, should contain a second dimension that follows latitudes. A "DST Zone". Lower latitudes can do without it as they please, and higher latitudes can maintain it. The local need for it. Granted, DST probably becomes irrelevant again above the arctic and antarctic circles. > On Dec 12, 2024, at 12:04, Brian Park <[email protected]> wrote: > > For some reason, I was less concerned about those systems which use some sort > of TZ database. Because I expect those systems to be explicitly designed to > handle updates to the TZ database. > > With regards to the hardcoded devices, it just occurred to me that many such > devices have the ability to turn off the "auto DST" feature. A permanent-STD > or permanent-DST would actually be ok, so the impact of permanent-XXX may not > be as bad as I thought. > > On Thu, Dec 12, 2024, at 08:54, Dale Ghent wrote: >> That's going to be tough and expensive on a personal level for sure. But the >> cost of that will probably be a rounding error on GDP calculations, which is >> what everyone pays attention to. There are other things that would need to >> be changed. Things like databases have their own built-in TZ tables to do >> operations such as date-time conversions. While the operating system they >> run on might get patched with an updated OS-level TZ database, things that >> ship their own (SQL servers of various sorts, Java runtimes, I think even >> PHP IIRC) will /also/ need to be updated to ensure any local time conversion >> functions stay correct. >> >> > On Dec 12, 2024, at 11:46, Brian Park via tz <[email protected]> wrote: >> > >> > One thing rarely mentioned in these discussions is the millions of >> > electronic devices (e.g. timers, clocks, watches, thermostats, etc) which >> > are hardcoded to handle DST using the current US/Canada rules (i.e. first >> > Sunday in Nov, second Sunday in Mar). If the DST rules are changed, those >> > devices will become obsolete because the firmware for those things will >> > never be updated. I own maybe 10-15 of such devices, and I would be >> > annoyed to throw away those items which are otherwise working perfectly >> > fine.
