permanent DST and North American time zone names
Regardless of what the legislation does or does not say, this database needs to quickly adopt a strategy to deal with changes that may be necessary for all North American Time zones. The supporters and maintainers of this time zone database can take an active role in helping to define and endorse a common standard, or they can sit back and watch the politicians and the general public fumble the job. It would be helpful if there was some collaboration between Microsoft and the supporters/maintainers of this database. I think it is likely that if the US government approves the Sunshine Protection Act, that most Canadian provinces and territories will follow with similar legislation. - British Columbia and Ontario already have the necessary legislation in place. - Saskatchewan has not changed its clocks in many years. - Yukon stopped changing its clocks in 2020. - Alberta recently voted to keep the biannual change, it could be the lone holdout! I admit I have not been following the other Canadian territories and provinces closely. Also, I have no clue what Mexico, Saint Pierre & Miquelon, or any of the small island nations will decide to do. For this database I can envision four options moving forward: *Option #1*: ditch the three letter time zone strings and use only numerical offsets from UTC. This is a complete cop out that says "Let's abandon our end users and let somebody else deal with the issue". It is my least favorite option. e.g. Los Angeles, Phoenix, and Vancouver: Thu Feb 1 00:00:00 *-07* 2024 (UTC-07) Thu Aug 1 00:00:00 *-07* 2024 (UTC-07) e.g. New York and Toronto: Thu Feb 1 00:00:00 *-04* 2024 (UTC-04) Thu Aug 1 00:00:00 *-04* 2024 (UTC-04) *Option #2*: allow permanent daylight saving This could be implemented without too many complications, but it goes against the philosophy that daylight saving is an alternate time offset that is only used for part of the year. This is not my favorite option even though it is probably the least disruptive. I do not think it will make any sense 20 years from now. e.g. Los Angeles, Phoenix, Vancouver, and Whitehorse would be on permanent *Pacific Daylight Time* Thu Feb 1 00:00:00 *PDT* 2024 (UTC-07) Thu Aug 1 00:00:00 *PDT* 2024 (UTC-07) e.g. New York and Toronto would be on permanent *Eastern Daylight Time*: Thu Feb 1 00:00:00 *EDT *2024 (UTC-04) Thu Aug 1 00:00:00 *EDT* 2024 (UTC-04) *Option #3*: move most North American entries in the TZ database one zone to the east: I know we have done this in the past for places such as America/Whitehorse, but I expect if we did it for all of Canada and the US it would not align with the public's perception of reality. Also, it provides no clear path to deal with any places that are currently using *Atlantic Daylight Time (UTC-03)*. e.g. Los Angeles, Phoenix, Vancouver, and Whitehorse would be on permanent *Mountain Standard Time* Thu Feb 1 00:00:00 *MST* 2024 (UTC-07) Thu Aug 1 00:00:00 *MST* 2024 (UTC-07) e.g. New York and Toronto would be on permanent *Atlantic Standard Time*: Thu Feb 1 00:00:00 *AST* 2024 (UTC-04) Thu Aug 1 00:00:00 *AST* 2024 (UTC-04) *Option #4*: redefine AKST, PST, MST, CST, EST, AST, and NST to all be one hour closer to UTC time. This is currently my preferred option even though it may break some software and it is guaranteed to conflict with the Canadian Interpretation Act. Alaska Standard Time (AKST) is redefined to UTC-08. Pacific Standard Time (PST) is redefined to UTC-07. Mountain Standard Time (MST) is redefined to UTC-06. Central Standard Time (CST) is redefined to UTC-05. Eastern Standard Time (EST) is redefined to UTC-04. Atlantic Standard Time (AST) is redefined to UTC-03. Newfoundland Standard Time (NST) is redefined to UTC-02:30 (assuming Newfoundland abandons the biannual time change) e.g. Los Angeles, Phoenix, Vancouver, and Whitehorse would be on *Pacific Standard Time* year-round: Thu Feb 1 00:00:00 *PST* 2024 (UTC-07) Thu Aug 1 00:00:00 *PST* 2024 (UTC-07) e.g. New York and Toronto would be on *Eastern Standard Time* year-round: Thu Feb 1 00:00:00 *EST* 2024 (UTC-04) Thu Aug 1 00:00:00 *EST* 2024 (UTC-04) e.g. Alberta would have to adopt new time zone names: *Pacific Standard Time* in winter, and *Pacific Daylight Time* in summer. (Alberta recently voted to keep the biannual clock change). Thu Feb 1 00:00:00 *PST* 2024 (UTC-07) Thu Aug 1 00:00:00 *PDT* 2024 (UTC-06) e.g. Saskatchewan would have to start referring to its time zone name as *Mountain Standard Time* instead of *Central Standard Time*. (Saskatchewan has used *UTC-06* year-round for many years) Thu Feb 1 00:00:00 *MST* 2024 (UTC-06) Thu Aug 1 00:00:00 *MST* 2024 (UTC-06) e.g. Puerto Rico would have to start referring to its time zone as *Eastern Standard Time* instead of *Atlantic Standard Time*. Thu Feb 1 00:00:00 *EST* 2024 (UTC-04) Thu Aug 1 00:00:00 *EST* 2024 (UTC-04) e.g. If Atlantic Canada and Bermuda were to continue changing the clocks twice a year, they would be on *Eastern Standard Time* in winter and *Eastern Daylight Time* in summer. Thu Feb 1 00:00:00 *EST* 2024 (UTC-04) Thu Aug 1 00:00:00 *EDT* 2024 (UTC-03) e.g. If, Atlantic Canada and Bermuda were to abandon the time change, then they would both end up on *Atlantic Standard Time* year-round. Thu Feb 1 00:00:00 *AST* 2024 (UTC-03) Thu Aug 1 00:00:00 *AST* 2024 (UTC-03) Did I miss anything? -chris
On 2022-03-16 12:45:51 (+0800), Chris Walton via tz wrote:
For this database I can envision four options moving forward:
*Option #1*: ditch the three letter time zone strings and use only numerical offsets from UTC. This is a complete cop out that says "Let's abandon our end users and let somebody else deal with the issue". It is my least favorite option.
This would actually be my favourite option. The absence of these strings would make the offsets unambiguous and remove confusing naming collisions. It would also be in line with the strings have have been removed from the tzdb already -- the ones that were made up by the tzdb and not in widespread use. I think it's too early to say / predict what strings will be in use if or when this legislation passes. By doing away with the strings, we could also avoid adding to the confusion that will inevitably take place. Philip -- Philip Paeps Senior Reality Engineer Alternative Enterprises
Chris Walton via tz <tz@iana.org> wrote on Wed, 16 Mar 2022 at 00:45:51 EDT in <CAG55VO6gi_jqBPzLOZZJEDLz13Dx2od-Ok3v+gOYr8XdnCN5HA@mail.gmail.com>: I do find Option 2 extremely appealing, that the US would continue to stay in EDT/CDT/MDT/PDT, and so maintain the UTC offsets that are well-known to all, especially well-known to the rest of the world.
*Option #2*: allow permanent daylight saving This could be implemented without too many complications, but it goes against the philosophy that daylight saving is an alternate time offset that is only used for part of the year. This is not my favorite option even though it is probably the least disruptive. I do not think it will make any sense 20 years from now. e.g. Los Angeles, Phoenix, Vancouver, and Whitehorse would be on permanent *Pacific Daylight Time* Thu Feb 1 00:00:00 *PDT* 2024 (UTC-07) Thu Aug 1 00:00:00 *PDT* 2024 (UTC-07) e.g. New York and Toronto would be on permanent *Eastern Daylight Time*: Thu Feb 1 00:00:00 *EDT *2024 (UTC-04) Thu Aug 1 00:00:00 *EDT* 2024 (UTC-04)
I don't think the "make any sense 20 years from now" argument holds. After a few years of regularly talking about Eastern Daylight Time, we'll accept EDT as the time we have and the label will feel opaque and people won't feel obliged to parse it, as happens with any element of language and semantics. Just as, you know, people can talk about a.m. and p.m. without thinking or knowing that they stand for ante meridiem and post meridiem. Or amplitude modulation :) Of course, that's not the only argument against doing this. -- jhawk@alum.mit.edu John Hawkinson
Another option would be to just delete the middle letter and use two-letter abbreviations -- e.g. EST/EDT -> ET On Wed, Mar 16, 2022 at 6:47 AM Chris Walton via tz <tz@iana.org> wrote:
Regardless of what the legislation does or does not say, this database needs to quickly adopt a strategy to deal with changes that may be necessary for all North American Time zones. The supporters and maintainers of this time zone database can take an active role in helping to define and endorse a common standard, or they can sit back and watch the politicians and the general public fumble the job. It would be helpful if there was some collaboration between Microsoft and the supporters/maintainers of this database.
I think it is likely that if the US government approves the Sunshine Protection Act, that most Canadian provinces and territories will follow with similar legislation. - British Columbia and Ontario already have the necessary legislation in place. - Saskatchewan has not changed its clocks in many years. - Yukon stopped changing its clocks in 2020. - Alberta recently voted to keep the biannual change, it could be the lone holdout! I admit I have not been following the other Canadian territories and provinces closely. Also, I have no clue what Mexico, Saint Pierre & Miquelon, or any of the small island nations will decide to do.
For this database I can envision four options moving forward:
*Option #1*: ditch the three letter time zone strings and use only numerical offsets from UTC. This is a complete cop out that says "Let's abandon our end users and let somebody else deal with the issue". It is my least favorite option. e.g. Los Angeles, Phoenix, and Vancouver: Thu Feb 1 00:00:00 *-07* 2024 (UTC-07) Thu Aug 1 00:00:00 *-07* 2024 (UTC-07) e.g. New York and Toronto: Thu Feb 1 00:00:00 *-04* 2024 (UTC-04) Thu Aug 1 00:00:00 *-04* 2024 (UTC-04)
*Option #2*: allow permanent daylight saving This could be implemented without too many complications, but it goes against the philosophy that daylight saving is an alternate time offset that is only used for part of the year. This is not my favorite option even though it is probably the least disruptive. I do not think it will make any sense 20 years from now. e.g. Los Angeles, Phoenix, Vancouver, and Whitehorse would be on permanent *Pacific Daylight Time* Thu Feb 1 00:00:00 *PDT* 2024 (UTC-07) Thu Aug 1 00:00:00 *PDT* 2024 (UTC-07) e.g. New York and Toronto would be on permanent *Eastern Daylight Time*: Thu Feb 1 00:00:00 *EDT *2024 (UTC-04) Thu Aug 1 00:00:00 *EDT* 2024 (UTC-04)
*Option #3*: move most North American entries in the TZ database one zone to the east: I know we have done this in the past for places such as America/Whitehorse, but I expect if we did it for all of Canada and the US it would not align with the public's perception of reality. Also, it provides no clear path to deal with any places that are currently using *Atlantic Daylight Time (UTC-03)*. e.g. Los Angeles, Phoenix, Vancouver, and Whitehorse would be on permanent *Mountain Standard Time* Thu Feb 1 00:00:00 *MST* 2024 (UTC-07) Thu Aug 1 00:00:00 *MST* 2024 (UTC-07) e.g. New York and Toronto would be on permanent *Atlantic Standard Time*: Thu Feb 1 00:00:00 *AST* 2024 (UTC-04) Thu Aug 1 00:00:00 *AST* 2024 (UTC-04)
*Option #4*: redefine AKST, PST, MST, CST, EST, AST, and NST to all be one hour closer to UTC time. This is currently my preferred option even though it may break some software and it is guaranteed to conflict with the Canadian Interpretation Act. Alaska Standard Time (AKST) is redefined to UTC-08. Pacific Standard Time (PST) is redefined to UTC-07. Mountain Standard Time (MST) is redefined to UTC-06. Central Standard Time (CST) is redefined to UTC-05. Eastern Standard Time (EST) is redefined to UTC-04. Atlantic Standard Time (AST) is redefined to UTC-03. Newfoundland Standard Time (NST) is redefined to UTC-02:30 (assuming Newfoundland abandons the biannual time change) e.g. Los Angeles, Phoenix, Vancouver, and Whitehorse would be on *Pacific Standard Time* year-round: Thu Feb 1 00:00:00 *PST* 2024 (UTC-07) Thu Aug 1 00:00:00 *PST* 2024 (UTC-07) e.g. New York and Toronto would be on *Eastern Standard Time* year-round: Thu Feb 1 00:00:00 *EST* 2024 (UTC-04) Thu Aug 1 00:00:00 *EST* 2024 (UTC-04) e.g. Alberta would have to adopt new time zone names: *Pacific Standard Time* in winter, and *Pacific Daylight Time* in summer. (Alberta recently voted to keep the biannual clock change). Thu Feb 1 00:00:00 *PST* 2024 (UTC-07) Thu Aug 1 00:00:00 *PDT* 2024 (UTC-06) e.g. Saskatchewan would have to start referring to its time zone name as *Mountain Standard Time* instead of *Central Standard Time*. (Saskatchewan has used *UTC-06* year-round for many years) Thu Feb 1 00:00:00 *MST* 2024 (UTC-06) Thu Aug 1 00:00:00 *MST* 2024 (UTC-06) e.g. Puerto Rico would have to start referring to its time zone as *Eastern Standard Time* instead of *Atlantic Standard Time*. Thu Feb 1 00:00:00 *EST* 2024 (UTC-04) Thu Aug 1 00:00:00 *EST* 2024 (UTC-04) e.g. If Atlantic Canada and Bermuda were to continue changing the clocks twice a year, they would be on *Eastern Standard Time* in winter and *Eastern Daylight Time* in summer. Thu Feb 1 00:00:00 *EST* 2024 (UTC-04) Thu Aug 1 00:00:00 *EDT* 2024 (UTC-03) e.g. If, Atlantic Canada and Bermuda were to abandon the time change, then they would both end up on *Atlantic Standard Time* year-round. Thu Feb 1 00:00:00 *AST* 2024 (UTC-03) Thu Aug 1 00:00:00 *AST* 2024 (UTC-03)
Did I miss anything? -chris
On 3/15/22 23:26, Ephraim Silverberg via tz wrote:
Another option would be to just delete the middle letter and use two-letter abbreviations -- e.g. EST/EDT -> ET
As I understand it, POSIX and Internet RFC 8536 both require at least three characters in time zone abbreviations. Of course the standards could be changed, but the corresponding software would need to be changed too.
Hearkening back to the resolution of 3/16/2022 versus 16/3/2022 with 2022-03-16: EPT, CPT, MPT, and PPT (where the middle P stands for permanent). An option: a middle Y for "year-round." The option with the most fun: a middle A for "all the," yielding four three-letter words as time zone abbreviations. @dashdashado On Wed, Mar 16, 2022, 10:40 AM Paul Eggert via tz <tz@iana.org> wrote:
On 3/15/22 23:26, Ephraim Silverberg via tz wrote:
Another option would be to just delete the middle letter and use two-letter abbreviations -- e.g. EST/EDT -> ET
As I understand it, POSIX and Internet RFC 8536 both require at least three characters in time zone abbreviations. Of course the standards could be changed, but the corresponding software would need to be changed too.
The tzdb aims to support the actual use of time zones, rather than necessarily what the laws say. In keeping with that idea, wouldn't it make sense for tzdb to use the abbreviations that people actually use after the transition to permanent DST is complete? The problem, of course, is that we won't know ahead of time what abbreviations to use. A reasonable guess, however, is that people will continue to use whatever abbreviations they have been using. Thus, Phoenix will continue calling its time MST, Los Angeles PDT and Denver MDT. If that changes, the tzdb can always be updated in response. John Sauter (John_Sauter@systemeyescomputerstore.com) -- get my PGP public key with gpg --locate-external-keys John_Sauter@systemeyescomputerstore.com
On Wed, 16 Mar 2022 at 11:10, John Sauter via tz <tz@iana.org> wrote:
The problem, of course, is that we won't know ahead of time what abbreviations to use. A reasonable guess, however, is that people will continue to use whatever abbreviations they have been using.
Complicating matters somewhat is that, because of the prevalence of tzdb, in a sense we're "victims of our own success". That is, whatever we end up picking will likely show up fairly automatically in a lot of public-facing places, and so even if it isn't what the public would've naturally used in the immediate aftermath of a change, many will be fairly quickly informed by what they start to see, and may start adopting and spreading whatever nomenclature we've picked. -- Tim Parenti
On Wed, 16 Mar 2022, Tim Parenti via tz wrote:
On Wed, 16 Mar 2022 at 11:10, John Sauter via tz <tz@iana.org> wrote:
The problem, of course, is that we won't know ahead of time what abbreviations to use. A reasonable guess, however, is that people will continue to use whatever abbreviations they have been using.
Complicating matters somewhat is that, because of the prevalence of tzdb, in a sense we're "victims of our own success". That is, whatever we end up picking will likely show up fairly automatically in a lot of public-facing places, and so even if it isn't what the public would've naturally used in the immediate aftermath of a change, many will be fairly quickly informed by what they start to see, and may start adopting and spreading whatever nomenclature we've picked.
Let's get really creative (and confusing) and switch to PSDT, MSDT, CSDT, and ESDT Oh, no, that means we'd end up back in the business of inventing zone abbreviations. :) So maybe we switch to <+n> nomenclature until boots-on-the-ground can provide more-or-less definitive "common usage" abbreviations. +--------------------+--------------------------+----------------------+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | paul@whooppee.com | | Software Developer | 0786 F758 55DE 53BA 7731 | pgoyette@netbsd.org | | & Network Engineer | | pgoyette99@gmail.com | +--------------------+--------------------------+----------------------+
On Mar 16, 2022, at 11:16, Tim Parenti via tz <tz@iana.org> wrote:
Complicating matters somewhat is that, because of the prevalence of tzdb, in a sense we're "victims of our own success". That is, whatever we end up picking will likely show up fairly automatically in a lot of public-facing places, and so even if it isn't what the public would've naturally used in the immediate aftermath of a change, many will be fairly quickly informed by what they start to see, and may start adopting and spreading whatever nomenclature we've picked.
With that in mind, I’m thinking that the best approach might be (to take a page from the Hippocratic Oath) to “do no harm”. Given that the overall thrust of the Bill is ‘permanent DST’, perhaps we should reflect just that —i.e. the “permanent” abbreviations would become EDT | CDT | MDT | PDT, the 'tm_isdst' member of the 'tm' struct would always return a positive value, etc. Doing this would narrowly confine the scope of the changes to DST transition handling itself; without the need to go change the meanings of abbreviations as defined in the relevant RFCs and other standards with the concomitant needed changes in downstream applications. Cheers! |---------------------------------------------------------------------| | Frederick F. Gleason, Jr. | Chief Developer | | | Paravel Systems | |---------------------------------------------------------------------| | A room without books is like a body without a soul. | | | | -- Cicero | |---------------------------------------------------------------------|
On 2022-03-16 11:44 AM, Fred Gleason via tz wrote:
On Mar 16, 2022, at 11:16, Tim Parenti via tz <tz@iana.org <mailto:tz@iana.org>> wrote:
Complicating matters somewhat is that, because of the prevalence of tzdb, in a sense we're "victims of our own success". That is, whatever we end up picking will likely show up fairly automatically in a lot of public-facing places, and so even if it isn't what the public would've naturally used in the immediate aftermath of a change, many will be fairly quickly informed by what they start to see, and may start adopting and spreading whatever nomenclature we've picked.
With that in mind, I’m thinking that the best approach might be (to take a page from the Hippocratic Oath) to “do no harm”. Given that the overall thrust of the Bill is ‘permanent DST’, perhaps we should reflect just that —i.e. the “permanent” abbreviations would become EDT | CDT | MDT | PDT, the 'tm_isdst' member of the 'tm' struct would always return a positive value, etc. This is what happened in America/New_York in 1942, except the abbreviations were EWT and EPT, right?
Rule US 1918 1919 - Oct lastSun 2:00 0 S Rule US 1942 only - Feb 9 2:00 1:00 W # War Rule US 1945 only - Aug 14 23:00u 1:00 P # Peace Rule US 1945 only - Sep 30 2:00 0 S -880218001 1942-02-09 01:59:59 EST isdst 0 gmtoff -18000 stdoff -18000 -880218000 1942-02-09 03:00:00 EWT isdst 1 gmtoff -14400 stdoff -18000 -769395601 1945-08-14 18:59:59 EWT isdst 1 gmtoff -14400 stdoff -18000 -769395600 1945-08-14 19:00:00 EPT isdst 1 gmtoff -14400 stdoff -18000 -765396001 1945-09-30 01:59:59 EPT isdst 1 gmtoff -14400 stdoff -18000 -765396000 1945-09-30 01:00:00 EST isdst 0 gmtoff -18000 stdoff -18000 -Brooks
Doing this would narrowly confine the scope of the changes to DST transition handling itself; without the need to go change the meanings of abbreviations as defined in the relevant RFCs and other standards with the concomitant needed changes in downstream applications.
Cheers!
|---------------------------------------------------------------------| | Frederick F. Gleason, Jr. | Chief Developer | | | Paravel Systems | |---------------------------------------------------------------------| | A room without books is like a body without a soul. | | | | -- Cicero | |---------------------------------------------------------------------|
On Wed, 16 Mar 2022 at 15:45, Fred Gleason via tz <tz@iana.org> wrote:
On Mar 16, 2022, at 11:16, Tim Parenti via tz <tz@iana.org> wrote:
Complicating matters somewhat is that, because of the prevalence of tzdb, in a sense we're "victims of our own success". That is, whatever we end up picking will likely show up fairly automatically in a lot of public-facing places, and so even if it isn't what the public would've naturally used in the immediate aftermath of a change, many will be fairly quickly informed by what they start to see, and may start adopting and spreading whatever nomenclature we've picked.
With that in mind, I’m thinking that the best approach might be (to take a page from the Hippocratic Oath) to “do no harm”. Given that the overall thrust of the Bill is ‘permanent DST’, perhaps we should reflect just that —i.e. the “permanent” abbreviations would become EDT | CDT | MDT | PDT, the 'tm_isdst' member of the 'tm' struct would always return a positive value, etc.
Doing this would narrowly confine the scope of the changes to DST transition handling itself; without the need to go change the meanings of abbreviations as defined in the relevant RFCs and other standards with the concomitant needed changes in downstream applications.
Alternatively, we could keep the central "D" but still make tm_isdst return false. The new meaning of "D" could be "Definitive" instead of "Daylight". There is precedent for something like this, in the UK: BST means both British Summer Time (the most common expansion) and British Standard Time (around 1970), with both having the same offset, but different meanings in terms of whether it was officially observing daylight savings. I *think* my tongue is firmly in my cheek, but then I go through brief periods of wondering if it's actually a reasonable approach...
On Wed, Mar 16, 2022 at 11:15 AM Tim Parenti via tz <tz@iana.org> wrote:
Complicating matters somewhat is that, because of the prevalence of tzdb, in a sense we're "victims of our own success". That is, whatever we end up picking will likely show up fairly automatically in a lot of public-facing places, and so even if it isn't what the public would've naturally used in the immediate aftermath of a change, many will be fairly quickly informed by what they start to see, and may start adopting and spreading whatever nomenclature we've picked.
This is a good thing. It is my opinion that the people who are best able to choose the time zone names and abbreviations are those that have the complete understanding of all North American time zone practices and idiosyncrasies. Those people happen to be the members of this mailing list. If decisions on standard time zone naming are left up to the politicians and the general public, the results will be unpredictable and inconsistent. My hope is for a common standard that crosses all National, provincial, state, and territorial borders; we already have such a standard today, but it will clearly require changes moving forward. If the changes are not well thought out, we will be left with a broken standard which will not properly serve the people of North America. -chris
On Wed, 16 Mar 2022 at 11:47, Chris Walton <crj.walton@gmail.com> wrote:
On Wed, Mar 16, 2022 at 11:15 AM Tim Parenti via tz <tz@iana.org> wrote:
Complicating matters somewhat is that, because of the prevalence of tzdb, in a sense we're "victims of our own success". That is, whatever we end up picking will likely show up fairly automatically in a lot of public-facing places, and so even if it isn't what the public would've naturally used in the immediate aftermath of a change, many will be fairly quickly informed by what they start to see, and may start adopting and spreading whatever nomenclature we've picked.
This is a good thing. It is my opinion that the people who are best able to choose the time zone names and abbreviations are those that have the complete understanding of all North American time zone practices and idiosyncrasies. Those people happen to be the members of this mailing list. If decisions on standard time zone naming are left up to the politicians and the general public, the results will be unpredictable and inconsistent.
Sure, but it *is* fundamentally at odds with the prevailing idea that we aim to be descriptive, not prescriptive. There is certainly always a role, though, for us to be good stewards and use our expertise to help guide best practices, so it's inevitably a balancing act. But we need to be clear-eyed that there is balancing being done and, as such, maintain the flexibility needed to manage that push and pull. -- Tim Parenti
On 16 Mar 2022, at 00.45, Chris Walton via tz <tz@iana.org> wrote:
Option #2: allow permanent daylight saving This could be implemented without too many complications, but it goes against the philosophy that daylight saving is an alternate time offset that is only used for part of the year. This is not my favorite option even though it is probably the least disruptive. I do not think it will make any sense 20 years from now. e.g. Los Angeles, Phoenix, Vancouver, and Whitehorse would be on permanent Pacific Daylight Time Thu Feb 1 00:00:00 PDT 2024 (UTC-07) Thu Aug 1 00:00:00 PDT 2024 (UTC-07) e.g. New York and Toronto would be on permanent Eastern Daylight Time: Thu Feb 1 00:00:00 EDT 2024 (UTC-04) Thu Aug 1 00:00:00 EDT 2024 (UTC-04)
Option #3: move most North American entries in the TZ database one zone to the east:
I would consider these options incorrect. While the bill is being called "permanent DST" (even in its own section heading), the actual implementation eliminates DST and defines all time zones as one hour earlier.
Option #4: redefine AKST, PST, MST, CST, EST, AST, and NST to all be one hour closer to UTC time. This is currently my preferred option even though it may break some software and it is guaranteed to conflict with the Canadian Interpretation Act.
I'm not familiar with the Canadian Interpretation Act, but I think you're referring to its definition of standard time? I would expect Canada to make the same change if the US does it first. Canada has followed previous US changes to DST, and it seems like the main reason they haven't done this already is to keep the same time zones as the US. On 16 Mar 2022, at 02.26, Ephraim Silverberg via tz <tz@iana.org> wrote:
Another option would be to just delete the middle letter and use two-letter abbreviations -- e.g. EST/EDT -> ET
Let's call this option 4b. I like the idea; there's no need to specify it's a standard time when that's the only kind it can be. It does seem like a slight change from its current meaning, though (something happening at the same time regardless of whether DST is in effect vs. the only time zone used in the region). I can't think of any reason that would matter, but it seems like exactly the sort of subtle distinction that breaks things. Of course, the ?ST names having a different meaning than they used to could *also* break things.
On Wed, Mar 16, 2022 at 3:43 AM Max Harmony <maxh@maxh.name> wrote:
I'm not familiar with the Canadian Interpretation Act, but I think you're referring to its definition of standard time? I would expect Canada to make the same change if the US does it first. Canada has followed previous US changes to DST, and it seems like the main reason they haven't done this already is to keep the same time zones as the US.
Section 35 of the Canadian (federal) Interpretation Act has definitions for Standard Time; it can be found here: https://laws-lois.justice.gc.ca/eng/acts/i-21/page-2.html?wbdisable=false#h-... It might be updated some day, but I would not hold my breath. The definitions for standard time in Yukon, Nunavut, and Quebec are very much outdated. i.e. the federal government has made no effort to keep its Interpretation Act in sync with territorial and provincial time legislation. Also keep in mind that each province and territory is responsible for its own time legislation. Provinces and territories are free to choose their own time zone(s) and they are free to adopt or reject the use of daylight saving. Realistically, the only people that might care about the wording in the federal Interpretation Act would be the criminal and/or corporate lawyers.
On 16 Mar 2022, at 02.26, Ephraim Silverberg via tz <tz@iana.org> wrote:
Another option would be to just delete the middle letter and use
two-letter abbreviations -- e.g. EST/EDT -> ET
Let's call this option 4b. I like the idea; there's no need to specify
it's a standard time when that's the only kind it can be. It does seem like a slight change from its current meaning, though (something happening at the same time regardless of whether DST is in effect vs. the only time zone used in the region). I can't think of any reason that would matter, but it seems like exactly the sort of subtle distinction that breaks things. Of course, the ?ST names having a different meaning than they used to could *also* break things. I agree, option 4b (using "ET" instead of "EST") is compelling. -chris
Perhaps lobby the House of Representatives to change the Bill to simply stop DST: A) Its a more natural reflection of daylight and seasons. Its more in keeping with the age old tradition of keeping time by the Sun in the sky. Its better for the population's sleep patterns and so better for safety, health and productivity. B) Its a simple matter for tzdb to accommodate that rule and for client systems to reflect it. There would be little or no technical disruption of civil time. I want DST to go away, but I see "permanent DST" as an unnatural distortion and technically disruptive. Perhaps if lawmakers were made more aware if this there might be reconsideration of the terms of the Bill. Thanks, -Brooks On 2022-03-16 12:45 AM, Chris Walton via tz wrote:
Regardless of what the legislation does or does not say, this database needs to quickly adopt a strategy to deal with changes that may be necessary for all North American Time zones. The supporters and maintainers of this time zone database can take an active role in helping to define and endorse a common standard, or they can sit back and watch the politicians and the general public fumble the job. It would be helpful if there was some collaboration between Microsoft and the supporters/maintainers of this database.
I think it is likely that if the US government approves the Sunshine Protection Act, that most Canadian provinces and territories will follow with similar legislation. - British Columbia and Ontario already have the necessary legislation in place. - Saskatchewan has not changed its clocks in many years. - Yukon stopped changing its clocks in 2020. - Alberta recently voted to keep the biannual change, it could be the lone holdout! I admit I have not been following the other Canadian territories and provinces closely. Also, I have no clue what Mexico, Saint Pierre & Miquelon, or any of the small island nations will decide to do.
For this database I can envision four options moving forward:
*Option #1*: ditch the three letter time zone strings and use only numerical offsets from UTC. This is a complete cop out that says "Let's abandon our end users and let somebody else deal with the issue". It is my least favorite option. e.g. Los Angeles, Phoenix, and Vancouver: Thu Feb 1 00:00:00 *-07* 2024 (UTC-07) Thu Aug 1 00:00:00 *-07* 2024 (UTC-07) e.g. New York and Toronto: Thu Feb 1 00:00:00 *-04* 2024 (UTC-04) Thu Aug 1 00:00:00 *-04* 2024 (UTC-04)
*Option #2*: allow permanent daylight saving This could be implemented without too many complications, but it goes against the philosophy that daylight saving is an alternate time offset that is only used for part of the year. This is not my favorite option even though it is probably the least disruptive. I do not think it will make any sense 20 years from now. e.g. Los Angeles, Phoenix, Vancouver, and Whitehorse would be on permanent *Pacific Daylight Time* Thu Feb 1 00:00:00 *PDT* 2024 (UTC-07) Thu Aug 1 00:00:00 *PDT* 2024 (UTC-07) e.g. New York and Toronto would be on permanent *Eastern Daylight Time*: Thu Feb 1 00:00:00 *EDT *2024 (UTC-04) Thu Aug 1 00:00:00 *EDT* 2024 (UTC-04)
*Option #3*: move most North American entries in the TZ database one zone to the east: I know we have done this in the past for places such as America/Whitehorse, but I expect if we did it for all of Canada and the US it would not align with the public's perception of reality. Also, it provides no clear path to deal with any places that are currently using *Atlantic Daylight Time (UTC-03)*. e.g. Los Angeles, Phoenix, Vancouver, and Whitehorse would be on permanent *Mountain Standard Time* Thu Feb 1 00:00:00 *MST* 2024 (UTC-07) Thu Aug 1 00:00:00 *MST* 2024 (UTC-07) e.g. New York and Toronto would be on permanent *Atlantic Standard Time*: Thu Feb 1 00:00:00 *AST* 2024 (UTC-04) Thu Aug 1 00:00:00 *AST* 2024 (UTC-04)
*Option #4*: redefine AKST, PST, MST, CST, EST, AST, and NST to all be one hour closer to UTC time. This is currently my preferred option even though it may break some software and it is guaranteed to conflict with the Canadian Interpretation Act. Alaska Standard Time (AKST) is redefined to UTC-08. Pacific Standard Time (PST) is redefined to UTC-07. Mountain Standard Time (MST) is redefined to UTC-06. Central Standard Time (CST) is redefined to UTC-05. Eastern Standard Time (EST) is redefined to UTC-04. Atlantic Standard Time (AST) is redefined to UTC-03. Newfoundland Standard Time (NST) is redefined to UTC-02:30 (assuming Newfoundland abandons the biannual time change) e.g. Los Angeles, Phoenix, Vancouver, and Whitehorse would be on *Pacific Standard Time* year-round: Thu Feb 1 00:00:00 *PST* 2024 (UTC-07) Thu Aug 1 00:00:00 *PST* 2024 (UTC-07) e.g. New York and Toronto would be on *Eastern Standard Time* year-round: Thu Feb 1 00:00:00 *EST* 2024 (UTC-04) Thu Aug 1 00:00:00 *EST* 2024 (UTC-04) e.g. Alberta would have to adopt new time zone names: *Pacific Standard Time* in winter, and *Pacific Daylight Time* in summer. (Alberta recently voted to keep the biannual clock change). Thu Feb 1 00:00:00 *PST* 2024 (UTC-07) Thu Aug 1 00:00:00 *PDT* 2024 (UTC-06) e.g. Saskatchewan would have to start referring to its time zone name as *Mountain Standard Time* instead of *Central Standard Time*. (Saskatchewan has used *UTC-06* year-round for many years) Thu Feb 1 00:00:00 *MST* 2024 (UTC-06) Thu Aug 1 00:00:00 *MST* 2024 (UTC-06) e.g. Puerto Rico would have to start referring to its time zone as *Eastern Standard Time* instead of *Atlantic Standard Time*. Thu Feb 1 00:00:00 *EST* 2024 (UTC-04) Thu Aug 1 00:00:00 *EST* 2024 (UTC-04) e.g. If Atlantic Canada and Bermuda were to continue changing the clocks twice a year, they would be on *Eastern Standard Time* in winter and *Eastern Daylight Time* in summer. Thu Feb 1 00:00:00 *EST* 2024 (UTC-04) Thu Aug 1 00:00:00 *EDT* 2024 (UTC-03) e.g. If, Atlantic Canada and Bermuda were to abandon the time change, then they would both end up on *Atlantic Standard Time* year-round. Thu Feb 1 00:00:00 *AST* 2024 (UTC-03) Thu Aug 1 00:00:00 *AST* 2024 (UTC-03)
Did I miss anything? -chris
Sleep experts say Senate has it wrong: Standard time, not daylight saving, should be permanent https://www.washingtonpost.com/wellness/2022/03/16/daylight-saving-bill-heal... -Brooks On 2022-03-16 9:53 AM, Brooks Harris via tz wrote:
Perhaps lobby the House of Representatives to change the Bill to simply stop DST:
A) Its a more natural reflection of daylight and seasons. Its more in keeping with the age old tradition of keeping time by the Sun in the sky. Its better for the population's sleep patterns and so better for safety, health and productivity.
B) Its a simple matter for tzdb to accommodate that rule and for client systems to reflect it. There would be little or no technical disruption of civil time.
I want DST to go away, but I see "permanent DST" as an unnatural distortion and technically disruptive. Perhaps if lawmakers were made more aware if this there might be reconsideration of the terms of the Bill.
Thanks, -Brooks
On 2022-03-16 12:45 AM, Chris Walton via tz wrote:
Regardless of what the legislation does or does not say, this database needs to quickly adopt a strategy to deal with changes that may be necessary for all North American Time zones. The supporters and maintainers of this time zone database can take an active role in helping to define and endorse a common standard, or they can sit back and watch the politicians and the general public fumble the job. It would be helpful if there was some collaboration between Microsoft and the supporters/maintainers of this database.
I think it is likely that if the US government approves the Sunshine Protection Act, that most Canadian provinces and territories will follow with similar legislation. - British Columbia and Ontario already have the necessary legislation in place. - Saskatchewan has not changed its clocks in many years. - Yukon stopped changing its clocks in 2020. - Alberta recently voted to keep the biannual change, it could be the lone holdout! I admit I have not been following the other Canadian territories and provinces closely. Also, I have no clue what Mexico, Saint Pierre & Miquelon, or any of the small island nations will decide to do.
For this database I can envision four options moving forward:
*Option #1*: ditch the three letter time zone strings and use only numerical offsets from UTC. This is a complete cop out that says "Let's abandon our end users and let somebody else deal with the issue". It is my least favorite option. e.g. Los Angeles, Phoenix, and Vancouver: Thu Feb 1 00:00:00 *-07* 2024 (UTC-07) Thu Aug 1 00:00:00 *-07* 2024 (UTC-07) e.g. New York and Toronto: Thu Feb 1 00:00:00 *-04* 2024 (UTC-04) Thu Aug 1 00:00:00 *-04* 2024 (UTC-04)
*Option #2*: allow permanent daylight saving This could be implemented without too many complications, but it goes against the philosophy that daylight saving is an alternate time offset that is only used for part of the year. This is not my favorite option even though it is probably the least disruptive. I do not think it will make any sense 20 years from now. e.g. Los Angeles, Phoenix, Vancouver, and Whitehorse would be on permanent *Pacific Daylight Time* Thu Feb 1 00:00:00 *PDT* 2024 (UTC-07) Thu Aug 1 00:00:00 *PDT* 2024 (UTC-07) e.g. New York and Toronto would be on permanent *Eastern Daylight Time*: Thu Feb 1 00:00:00 *EDT *2024 (UTC-04) Thu Aug 1 00:00:00 *EDT* 2024 (UTC-04)
*Option #3*: move most North American entries in the TZ database one zone to the east: I know we have done this in the past for places such as America/Whitehorse, but I expect if we did it for all of Canada and the US it would not align with the public's perception of reality. Also, it provides no clear path to deal with any places that are currently using *Atlantic Daylight Time (UTC-03)*. e.g. Los Angeles, Phoenix, Vancouver, and Whitehorse would be on permanent *Mountain Standard Time* Thu Feb 1 00:00:00 *MST* 2024 (UTC-07) Thu Aug 1 00:00:00 *MST* 2024 (UTC-07) e.g. New York and Toronto would be on permanent *Atlantic Standard Time*: Thu Feb 1 00:00:00 *AST* 2024 (UTC-04) Thu Aug 1 00:00:00 *AST* 2024 (UTC-04)
*Option #4*: redefine AKST, PST, MST, CST, EST, AST, and NST to all be one hour closer to UTC time. This is currently my preferred option even though it may break some software and it is guaranteed to conflict with the Canadian Interpretation Act. Alaska Standard Time (AKST) is redefined to UTC-08. Pacific Standard Time (PST) is redefined to UTC-07. Mountain Standard Time (MST) is redefined to UTC-06. Central Standard Time (CST) is redefined to UTC-05. Eastern Standard Time (EST) is redefined to UTC-04. Atlantic Standard Time (AST) is redefined to UTC-03. Newfoundland Standard Time (NST) is redefined to UTC-02:30 (assuming Newfoundland abandons the biannual time change) e.g. Los Angeles, Phoenix, Vancouver, and Whitehorse would be on *Pacific Standard Time* year-round: Thu Feb 1 00:00:00 *PST* 2024 (UTC-07) Thu Aug 1 00:00:00 *PST* 2024 (UTC-07) e.g. New York and Toronto would be on *Eastern Standard Time* year-round: Thu Feb 1 00:00:00 *EST* 2024 (UTC-04) Thu Aug 1 00:00:00 *EST* 2024 (UTC-04) e.g. Alberta would have to adopt new time zone names: *Pacific Standard Time* in winter, and *Pacific Daylight Time* in summer. (Alberta recently voted to keep the biannual clock change). Thu Feb 1 00:00:00 *PST* 2024 (UTC-07) Thu Aug 1 00:00:00 *PDT* 2024 (UTC-06) e.g. Saskatchewan would have to start referring to its time zone name as *Mountain Standard Time* instead of *Central Standard Time*. (Saskatchewan has used *UTC-06* year-round for many years) Thu Feb 1 00:00:00 *MST* 2024 (UTC-06) Thu Aug 1 00:00:00 *MST* 2024 (UTC-06) e.g. Puerto Rico would have to start referring to its time zone as *Eastern Standard Time* instead of *Atlantic Standard Time*. Thu Feb 1 00:00:00 *EST* 2024 (UTC-04) Thu Aug 1 00:00:00 *EST* 2024 (UTC-04) e.g. If Atlantic Canada and Bermuda were to continue changing the clocks twice a year, they would be on *Eastern Standard Time* in winter and *Eastern Daylight Time* in summer. Thu Feb 1 00:00:00 *EST* 2024 (UTC-04) Thu Aug 1 00:00:00 *EDT* 2024 (UTC-03) e.g. If, Atlantic Canada and Bermuda were to abandon the time change, then they would both end up on *Atlantic Standard Time* year-round. Thu Feb 1 00:00:00 *AST* 2024 (UTC-03) Thu Aug 1 00:00:00 *AST* 2024 (UTC-03)
Did I miss anything? -chris
participants (13)
-
Arthur David Olson -
Brooks Harris -
Chris Walton -
Ephraim Silverberg -
Fred Gleason -
John Hawkinson -
John Sauter -
Jon Skeet -
Max Harmony -
Paul Eggert -
Paul Goyette -
Philip Paeps -
Tim Parenti