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.

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 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 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, 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 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

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