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 <tz@iana.org> 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.