How permanent daylight saving time or permanent standard time would affect the USA
Article in the Washington Post about how early or late you would be in the dark if the USA adopted permanent daylight saving time or permanent standard time (compared with now). https://www.washingtonpost.com/nation/interactive/2024/no-daylight-saving-ti... With decent interactive graphics. I'm a subscriber; I don't know if there's a paywall in place. -- Jonathan Leffler <jonathan.leffler@gmail.com> #include <disclaimer.h> Guardian of DBD::Informix - v2018.1031 - http://dbi.perl.org "Blessed are we who can laugh at ourselves, for we shall never cease to be amused."
On 2024-12-12 (Thu) 15:25:10+09:00, Jonathan Leffler via tz <tz@iana.org> wrote:
https://www.washingtonpost.com/nation/interactive/2024/no-daylight-saving-ti...
With decent interactive graphics. I'm a subscriber; I don't know if there's a paywall in place.
I'm not a subscriber, and I only see the title and 'subscribe to see the article' paywall. (Not even the first paragraph) -- ---- revi | 레비 (IPA: lɛbi) - https://revi.xyz - he/him <https://revi.xyz/pronoun-is/> - What time is it in my timezone? <https://issuetracker.revi.xyz/u/time> - OpenPGP <https://revi.xyz/pgp/> - My texts (excluding quotes marked with `>`) to public mailing lists are licensed under CC BY ND 2.0 KR <https://creativecommons.org/licenses/by-nd/2.0/kr/>. - I reply when my time permits. Don't feel pressured to reply ASAP; take your time and respond at your schedule.
On Wed, Dec 11, 2024 at 11:43 PM 레비 (revi) via tz <tz@iana.org> wrote:
On 2024-12-12 (Thu) 15:25:10+09:00, Jonathan Leffler via tz <tz@iana.org> wrote:
https://www.washingtonpost.com/nation/interactive/2024/no-daylight-saving-ti...
With decent interactive graphics. I'm a subscriber; I don't know if there's a paywall in place.
I'm not a subscriber, and I only see the title and 'subscribe to see the article' paywall. (Not even the first paragraph)
Thanks for the paywall information — and I'm sorry that it is not available to non-subscribers. -- Jonathan Leffler <jonathan.leffler@gmail.com> #include <disclaimer.h> Guardian of DBD::Informix - v2018.1031 - http://dbi.perl.org "Blessed are we who can laugh at ourselves, for we shall never cease to be amused."
On Dec 11, 2024, at 10:42 PM, 레비 (revi) via tz <tz@iana.org> wrote:
On 2024-12-12 (Thu) 15:25:10+09:00, Jonathan Leffler via tz <tz@iana.org> wrote:
https://www.washingtonpost.com/nation/interactive/2024/no-daylight-saving-ti...
I'm not a subscriber, and I only see the title and 'subscribe to see the article' paywall. (Not even the first paragraph)
Sharing a "gift" link as a subscriber (not sure how many clicks are allowed on gift links though): https://wapo.st/3VDpi9N
This one should be indefinite: https://archive.is/xALBS On Thu, 12 Dec 2024 at 07:14, Axel Jessen via tz <tz@iana.org> wrote:
On Dec 11, 2024, at 10:42 PM, 레비 (revi) via tz <tz@iana.org> wrote:
On 2024-12-12 (Thu) 15:25:10+09:00, Jonathan Leffler via tz <tz@iana.org> wrote:
https://www.washingtonpost.com/nation/interactive/2024/no-daylight-saving-ti...
I'm not a subscriber, and I only see the title and 'subscribe to see the article' paywall. (Not even the first paragraph)
Sharing a "gift" link as a subscriber (not sure how many clicks are allowed on gift links though): https://wapo.st/3VDpi9N
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.
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.
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.
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 <brian@xparks.net> 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 <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.
It is true that DST is a bigger deal the further away one is from the equator, but it is also an issue for ridiculously longitudinally large timezones like the US Central TZ. The argument in favor of getting rid of the time change is grounded in chronobiology. For humans, it imposes a sort of twice a year minor jet lag. For farm animals it makes no difference because their circadian cycles are set to the sun, not the clock. For house pets it creates problems when the dog thinks it is time for food and the owner is looking at the clock. I think this debate could be solved if we shortened work days and school days and just let everyone sleep in 😊 Cheers, Kevin -- "Time is the measure of a wobbly world, and things slipping away." Rabanus Maurus, 9th century. Kevin K. Birth Professor Department of Anthropology Queens College and The Graduate Center, CUNY Flushing, NY 11367 (718) 997-5518 From: Dale Ghent via tz <tz@iana.org> Date: Thursday, December 12, 2024 at 12:30 PM To: Brian Park <brian@xparks.net> Cc: IANA TZ Database <tz@iana.org> Subject: [tz] Re: How permanent daylight saving time or permanent standard time would affect the USA * This email originates from a sender outside of CUNY. Verify the sender before replying or clicking on links and attachments. * 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 <brian@xparks.net> 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 <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.
Not really much difference above ~50 with fairly long dark nights in winter and fairly long sunny days in summer: many parents complain about difficulty getting kids to go to bed and get to sleep in summer. The DST change means you are driving into the sun for a month before and after each time change, on the way either to or from work, increasing accidents, whereas it would just be about a month total without the time changes. It would be better if times were better aligned to longitudes: I am in Mountain (Edmonton ~7.5hr), but that is better aligned for US Rockies (Denver ~ 7hr) than Canadian Rockies, which are closer to Pacific (L.A. and Dawson Creek ~8hr): 115-119° -> 7.6-7.9hr; coastal B.C. is closer to Alaska 123-135° -> 8.2-9hr. -- Take care. Thanks, Brian Inglis Calgary, Alberta, Canada La perfection est atteinte Perfection is achieved non pas lorsqu'il n'y a plus rien à ajouter not when there is no more to add mais lorsqu'il n'y a plus rien à retirer but when there is no more to cut -- Antoine de Saint-Exupéry On 2024-12-12 11:02, Kevin Birth via tz wrote:
It is true that DST is a bigger deal the further away one is from the equator, but it is also an issue for ridiculously longitudinally large timezones like the US Central TZ.
The argument in favor of getting rid of the time change is grounded in chronobiology. For humans, it imposes a sort of twice a year minor jet lag. For farm animals it makes no difference because their circadian cycles are set to the sun, not the clock. For house pets it creates problems when the dog thinks it is time for food and the owner is looking at the clock.
I think this debate could be solved if we shortened work days and school days and just let everyone sleep in 😊
On Thursday, December 12, 2024 at 12:30 PM, Dale Ghent via tz wrote:> 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 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 <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.
On Dec 12, 2024, at 9:27 AM, Dale Ghent via tz <tz@iana.org> wrote:
All this foo about DST in the US
Foo about DST in the US back in the 1980s was the original provocation for creating the tzdb in the first place. But the goal was more than "yet another tweak", so they ended up creating something that did a far better job of handling *multiple* locales than "have some rules compiled into the code", which was what UN*Xes had at the time.
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.
"Our" presumably referring to the organizations that draw those more-or-less vertical lines on the map, not to the maintainers of the tzdb, whose zones don't align up longitudinally.
On Dec 12, 2024, at 8:46 AM, 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.
So do they sell special models in Arizona (along with the regular model, for residents of the Navajo Nation)? Or do they have, for example, a switch that controls whether to observe DST or not?
At least for clocks, I have seen (used, owned) a number of WWV controlled models with: - a slide switch for the zone (EST/CST/MST/PST) - a DST on/off switch Example: https://www.pinterest.com/pin/cool-clock-with-dst-switch--108227197265304889... -- Steven R. Loomis Code Hive Tx, LLC https://codehivetx.us
On Dec 13, 2024, at 12:48 AM, Guy Harris via tz <tz@iana.org> wrote:
On Dec 12, 2024, at 8:46 AM, 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.
So do they sell special models in Arizona (along with the regular model, for residents of the Navajo Nation)?
Or do they have, for example, a switch that controls whether to observe DST or not?
<<On Thu, 12 Dec 2024 22:48:35 -0800, Guy Harris via tz <tz@iana.org> said:
Or do they have, for example, a switch that controls whether to observe DST or not?
The WWVB-synced alarm clocks that I have had instructed users in Arizona (and, at the time, Indiana) to change their time zone setting when the rest of the country switches. They did not have a "disable DST" setting. Curiously, although WWVB transmits a flag bit for "DST in effect", the first such clock I had did not use it, and I had to get a new one when the rules changed. -GAWollman
On 2024-12-12 23:48, Guy Harris via tz wrote:
On Dec 12, 2024, at 8:46 AM, Brian Park via tz 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.
So do they sell special models in Arizona (along with the regular model, for residents of the Navajo Nation)?
Or do they have, for example, a switch that controls whether to observe DST or not?
Most of them seem to, but unless they receive and use an RC DST flag rather than rules, they will not switch at the right time, as in 2007: $ zdump -Vc2007,2008 Navajo Navajo Sun Mar 11 08:59:59 2007 UT = Sun Mar 11 01:59:59 2007 MST isdst=0 gmtoff=-25200 Navajo Sun Mar 11 09:00:00 2007 UT = Sun Mar 11 03:00:00 2007 MDT isdst=1 gmtoff=-21600 Navajo Sun Nov 4 07:59:59 2007 UT = Sun Nov 4 01:59:59 2007 MDT isdst=1 gmtoff=-21600 Navajo Sun Nov 4 08:00:00 2007 UT = Sun Nov 4 01:00:00 2007 MST isdst=0 gmtoff=-25200 -- Take care. Thanks, Brian Inglis Calgary, Alberta, Canada La perfection est atteinte Perfection is achieved non pas lorsqu'il n'y a plus rien à ajouter not when there is no more to add mais lorsqu'il n'y a plus rien à retirer but when there is no more to cut -- Antoine de Saint-Exupéry
"레" == 레비 (revi) via tz <tz@iana.org> writes:
레> I'm not a subscriber, and I only see the title and 'subscribe to see the article' paywall. (Not even the first paragraph) try w/o ECMAscript. -JimC -- James Cloos <cloos@jhcloos.com> OpenPGP: https://jhcloos.com/0x997A9F17ED7DAEA6.asc
participants (12)
-
Almaz Mingaleev -
Axel Jessen -
Brian Park -
brian.inglis＠systematicsw.ab.ca -
Dale Ghent -
Garrett Wollman -
Guy Harris -
James Cloos -
Jonathan Leffler -
Kevin Birth -
Steven R. Loomis -
레비 (revi)