Request to delay America/Vancouver tm_isdst transition until November
The change in 8b46071 <https://github.com/eggert/tz/commit/8b46071fd85a7a9434d63894bac64d30362cc16d> sets America/Vancouver's tm_isdst flag to false starting this Monday. Because CLDR keys its display names by this flag, this change will cause ICU and other downstream software (including major operating systems) to display BC’s UTC-7 as "Pacific Standard Time," while Los Angeles’ UTC-7 will display as "Pacific Daylight Time." The CLDR and ICU Technical Committees have evaluated several immediate paths forward, including new display names or a generic "UTC-7" (both of which are not sensitive to the tm_isdst value). However, due to the tight timeline (CLDR releases don't propagate as quickly as TZDB releases), and the uncertainty around the name that will actually be used in the real world, we have determined that continuing to use "Pacific Daylight Time" through this summer is the least confusing solution for users, as it maintains alignment across the Pacific Time corridor until BC actually diverges in November. To support this, we ask that the change to the tm_isdst flag be delayed until November, at least in the rearguard version of the TZDB. This will give us time to determine the name that people will be using, remodel CLDR's data, acquire translations, and ship a release to devices. Best regards, Robert *(On behalf of the CLDR/ICU Technical Committees)*
On 2026-03-06 08:11, Robert Bastian via tz wrote:
Because CLDR keys its display names by this flag, this change will cause ICU and other downstream software (including major operating systems) to display BC’s UTC-7 as "Pacific Standard Time," while Los Angeles’ UTC-7 will display as "Pacific Daylight Time."
Yes, and what's currently in the draft TZDB on GitHub (America/Vancouver switching to abbreviation "-07") was intended to be merely a placeholder. We weren't intending to publish it as 2026b. For the reason you mention and for other software-compatibility reasons, let's change the "-07" placeholder to an alphabetic abbreviation. The simplest fix appears to be to change to the abbreviation "MST", as is already the case for America/Vancouver's geographic neighbors that observe UTC-7 all year. This should fix the CLDR issue (albeit in a different way than what you suggested), and should be good enough until the BC government and/or common practice advises us all later on what three-or-more-character abbreviation is most popular. Of course we'd prefer to make just one change now, and no changes later, but it seems we do not have that luxury given the rushed way this was done legally. And I would rather publish something before the actual legal change occurs on Monday, rather than issue a post-facto change.
Our issue is not with abbreviations (-07/MST), and changing the abbreviation to MST will not fix the issue. ICU checks whether a rule applies (tm_isdst), and chooses the DST name if one does. A change that would be compatible with current CLDR data is: Rule Vanc 2026 only - Mar 9 0:00 1:00 D # Zone NAME STDOFF RULES FORMAT [UNTIL] Zone America/Vancouver -8:12:28 - LMT 1884 -8:00 Vanc P%sT 1987 -8:00 Canada P%sT (any time before 2026-11-01) -8:00 Vanc (P%sT, MST, -07, whatever) This keeps tm_isdst true for eternity; that's obviously not ideal, but we can come back and fix this when we know more, and when CLDR can handle such a change. On Fri, 6 Mar 2026 at 19:39, Paul Eggert <eggert@cs.ucla.edu> wrote:
On 2026-03-06 08:11, Robert Bastian via tz wrote:
Because CLDR keys its display names by this flag, this change will cause ICU and other downstream software (including major operating systems) to display BC’s UTC-7 as "Pacific Standard Time," while Los Angeles’ UTC-7 will display as "Pacific Daylight Time."
Yes, and what's currently in the draft TZDB on GitHub (America/Vancouver switching to abbreviation "-07") was intended to be merely a placeholder. We weren't intending to publish it as 2026b.
For the reason you mention and for other software-compatibility reasons, let's change the "-07" placeholder to an alphabetic abbreviation. The simplest fix appears to be to change to the abbreviation "MST", as is already the case for America/Vancouver's geographic neighbors that observe UTC-7 all year. This should fix the CLDR issue (albeit in a different way than what you suggested), and should be good enough until the BC government and/or common practice advises us all later on what three-or-more-character abbreviation is most popular.
Of course we'd prefer to make just one change now, and no changes later, but it seems we do not have that luxury given the rushed way this was done legally. And I would rather publish something before the actual legal change occurs on Monday, rather than issue a post-facto change.
On 2026-03-06 11:02, Robert Bastian wrote:
Our issue is not with abbreviations (-07/MST), and changing the abbreviation to MST will not fix the issue. ICU checks whether a rule applies (tm_isdst), and chooses the DST name if one does.
Unfortunately I'm not following. If the abbreviation is "MST" and tm_isdst==0, what doesn't work? Several timezones do exactly that already: America/Dawson, America/Whitehorse, America/Dawson_Creek, America/Fort_Nelson, America/Phoenix, America/Hermosillo. Many of these timezones made a change in a past year that is pretty much what America/Vancouver is doing this year. If they don't work why not? and if they do work then what's different in this new case?
All that ICU sees is tm_isdst=0. The link between time zones and their "metazone", which determine display names, comes from CLDR. See here <https://github.com/unicode-org/cldr/blob/edc66fb4354f8ee6debbcf94faeb5496b38...> for America/Vancouver and here <https://github.com/unicode-org/cldr/blob/edc66fb4354f8ee6debbcf94faeb5496b38...> for America/Dawson_Creek, and for example French display names here <https://github.com/unicode-org/cldr/blob/edc66fb4354f8ee6debbcf94faeb5496b38...> . Linking Vancouver to Mountain Time names would require a CLDR release, which would definitely not reach devices by Monday, and more importantly, is not actually what we want. CLDR tries to match common usage, and common usage of "Mountain Standard Time" for UTC-7 in BC has just not been demonstrated. Changing BC to Mountain Time names next week is going to confuse end users, especially if we then change to yet another name in a few months. If it turns out that Mountain Standard Time is the best display name for BC, we will update our mapping to select Mountain Standard Time, but for now we want to keep Pacific Daylight Time.
Several timezones do exactly that already: America/Dawson, America/Whitehorse, America/Dawson_Creek, America/Fort_Nelson, America/Phoenix, America/Hermosillo. Many of these timezones made a change in a past year that is pretty much what America/Vancouver is doing this year. If they don't work why not? and if they do work then what's different in this new case?
Many of these time zones were newly created in the TZDB when they changed their offset. If that happens, ICU will just display the offset, which isn't great, but at least it's not showing a wrong name. We usually also had more than a week's notice to deploy these changes, and it was usually obvious what names to use. I'm also interested in which legislation you saw that says this change to "Pacific Time" happens at midnight on Monday? On Fri, 6 Mar 2026 at 21:07, Paul Eggert <eggert@cs.ucla.edu> wrote:
On 2026-03-06 11:02, Robert Bastian wrote:
Our issue is not with abbreviations (-07/MST), and changing the abbreviation to MST will not fix the issue. ICU checks whether a rule applies (tm_isdst), and chooses the DST name if one does.
Unfortunately I'm not following. If the abbreviation is "MST" and tm_isdst==0, what doesn't work?
Several timezones do exactly that already: America/Dawson, America/Whitehorse, America/Dawson_Creek, America/Fort_Nelson, America/Phoenix, America/Hermosillo. Many of these timezones made a change in a past year that is pretty much what America/Vancouver is doing this year. If they don't work why not? and if they do work then what's different in this new case?
On 2026-03-06 12:47, Robert Bastian wrote:
CLDR tries to match common usage, and common usage of "Mountain Standard Time" for UTC-7 in BC has just not been demonstrated.
I assume you meant "in America/Vancouver" not "in BC", as "Mountain Standard Time" has long been common usage in some parts of eastern BC. Unfortunately if we wait for common usage to be demonstrated for the Vancouver area we'll have to wait for months, and for reasons I hope are obvious we shouldn't do that - certainly not until November. We have a law and a press release from the BC Attorney General's office saying "Pacific Time". So my guess is that CLDR will go with "Pacific Time" for now, and then change later if a different name evolves. Of course these details are up to CLDR. How about this idea? 1. CLDR puts out a new version or patch today that outputs the name "Pacific Time" for America/Vancouver timestamps starting March 9, regardless of whether the tm_isdst flag is 1 or 0 for those timestamps. The idea is that this new CLDR version will work for America/Vancouver regardless of whether the associated TZDB version is 2026a or 2026b. The spelling of the string "Pacific Time" is entirely up to you; if you prefer "Pacific Daylight Time" then by all means use that. 2. TZDB puts out a release 2026b today that changes tm_isdst to 0. 3. Downstream users are advised to update CLDR if they update TZDB. Would that work for you? Quite possibly the "today" is a bit fast but the point is that we should not wait for months to get going on this. The ship is sailing Monday, not in November. Putting things off is not a good strategy.
I'm also interested in which legislation you saw that says this change to "Pacific Time" happens at midnight on Monday?
The name "Pacific Time" is specified by the Interpretation Amendment Act, 2019, SBC 2019, c 41 <https://canlii.ca/t/55ht0>. That act comes into force on Monday, March 9 by BC Order In Council 36/2026 <https://www.bclaws.gov.bc.ca/civix/document/id/oic/oic_cur/0063_2026>. The OIC does not specify time of day, which means it comes into force at the start of the day; see <https://www.bclaws.gov.bc.ca/civix/document/id/consol15/consol15/00_96238_01...>.
Date: Fri, 6 Mar 2026 14:11:13 -0800 From: Paul Eggert via tz <tz@iana.org> Message-ID: <68133738-be92-41f5-b763-64fa87692e71@cs.ucla.edu> | Unfortunately if we wait for common usage to be demonstrated for the | Vancouver area we'll have to wait for months, and for reasons I hope are | obvious we shouldn't do that - certainly not until November. The reasons aren't obvious to me. As best I can tell, using the current tzdata (the gtz version, if it matters, which it doesn't for this): jacaranda$ TZ=America/Vancouver date Fri Mar 6 14:50:33 PST 2026 jacaranda$ TZ=America/Vancouver date -d '+ 4 days' Tue Mar 10 15:50:49 PDT 2026 which as best I can tell is correct, with the possible minor exception of "PDT" instead of "we don't know yet", and tm_isdst==1 (which I am fairly sure the act/regulation/order/... says nothing about at all). This looks to me not to really be a "hurry and make a change so it can operate next week" but "hurry and make a change that will apply towards the end of the year, but needs to be made now before our authority to do it is removed". That is, there is really no urgency for either the tz project, or CLDR, to do anything at all (this month anyway, or next for that matter). Further, your desire to follow the letter of the law is kind of quaint, given that you changed "EST" (for Australia/Melbourne) to be AEST/AEDT despite the law (an act of the applicable Parliament) calling the times "Eastern Standard Time" and "Eastern Summer Time" (no mention of either "Australia" or "Daylight" - but instead relied upon information for foreign tourists provided on some web page). kre
On 2026-03-06 15:01, Robert Elz wrote:
This looks to me not to really be a "hurry and make a change so it can operate next week" but "hurry and make a change that will apply towards the end of the year, but needs to be made now before our authority to do it is removed".
Not sure what is meant by "authority" but that is not the motivation. The motivation is that it's better to change TZDB before the events it describes, rather than changing retroactively. Obviously we can't always be proactive, but proactive is better when possible.
your desire to follow the letter of the law is kind of quaint, given that you changed "EST"
Oh, please, let's not let old beefs derail solutions to new problems....
Date: Fri, 6 Mar 2026 16:56:10 -0800 From: Paul Eggert <eggert@cs.ucla.edu> Message-ID: <c476868c-2f1c-4731-bb33-be2fbcebd88d@cs.ucla.edu> | > This looks to me not to really be a "hurry and make a change so it can | > operate next week" but "hurry and make a change that will apply towards | > the end of the year, but needs to be made now before our authority to do | > it is removed". | | Not sure what is meant by "authority" but that is not the motivation. No, that's a misunderstanding of what I meant, probably my fault. I meant the change made by whoever made it in BC - from what I read (here, on this list, so it may be incorrect) they wanted to make the change, to be effective in November this year (or whenever the next return to standard time was to occur) but were not assured of being able to make any change for much longer (after now), so they legislated it now, with the intent (which seems clear in what I have read of the wording) to have practical effect from November (or ...). That is, no immediate change needs to occur, everything remains as it was, for all practical purposes, until the subsequent change. What will break exactly, if nothing in tzdata is altered for this for a month or three? | The motivation is that it's better to change TZDB before the events it | describes, rather than changing retroactively. Obviously we can't always | be proactive, but proactive is better when possible. Certainly, so a tzdata update for this, sometime in the next few months (say by May or June or so at the latest) would seem like a wise choice - once things have had more time to settle. I don't see anything being required in the next few weeks. For all we know, some "higher power" might override this planned change. | > your desire to follow the letter of the law is kind of quaint, | > given that you changed "EST" | | Oh, please, let's not let old beefs derail solutions to new problems.... It is all about precedents. Either the local laws are important, or they are not, you decide which of those applies, and apply that consistently. kre
Some background information inspired by some of the discussion.
The simplest fix appears to be to change to the abbreviation "MST", as is already the case for America/Vancouver's geographic neighbors that observe UTC-7 all year. This should fix the CLDR issue (albeit in a different way than what you suggested)
1. CLDR (and the software that uses it) does not use the TZDB abbreviations at all; it only depends on the timezone ID, and the offsets & tm_isdst flags produced by the TZDB rules. 2. CLDR provides support for 6 formats for time zone names, and four of those have long and short forms: so 10 combinations. ( https://unicode.org/reports/tr35/tr35-dates.html#using-time-zone-names). There is curated data to support the construction of these formats for all of the current* time zones for over 100 languages. The names (long and short) for each timezone are chosen to match as closely as possible what is used in each language (with possible country variations as well). The first of those formats is "Generic non-location format", like "Pacific Time". A meeting that happens at "13:00 Pacific Time" means that it happens at different UTC times during the summer and winter; it is driven by the wall time in a metazone spanning the multiple timezone IDs that use something called "Pacific Time". Using the name "Pacific Time" for both a fixed time and one that observes daylight savings will clearly cause confusion among people all over the US and Canada (and beyond).
Downstream users are advised to update CLDR if they update TZDB.
3. CLDR is used in essentially all* consumer-facing mobile phones, desktop/laptop operating systems, and many other products. Most of those products have mechanisms to update to a new version of the TZDB data tables; however, many of them do *not* have mechanisms to immediately update the CLDR data. One can 'advise' users as much as one wants, but the facts on the ground are that for months (with some products, many months), if the tm_isdst flag is flipped, people will see "Pacific Daylight Time". As Robert said, "CLDR releases don't propagate as quickly as TZDB releases". The best we could probably do is advise all products using CLDR directly or indirectly to either not update to the TDBC data release, or to patch the tm_isdst flag. 4. The population of people living in the region covered by America/Vancouver is roughly 100 times the population of Yukon; so an approach taken for the latter doesn't necessarily scale to the former. (And of course, the population indirectly affected is far greater than the population of BC.) Mark On Fri, Mar 6, 2026 at 2:11 PM Paul Eggert via tz <tz@iana.org> wrote:
On 2026-03-06 12:47, Robert Bastian wrote:
CLDR tries to match common usage, and common usage of "Mountain Standard Time" for UTC-7 in BC has just not been demonstrated.
I assume you meant "in America/Vancouver" not "in BC", as "Mountain Standard Time" has long been common usage in some parts of eastern BC.
Unfortunately if we wait for common usage to be demonstrated for the Vancouver area we'll have to wait for months, and for reasons I hope are obvious we shouldn't do that - certainly not until November.
We have a law and a press release from the BC Attorney General's office saying "Pacific Time". So my guess is that CLDR will go with "Pacific Time" for now, and then change later if a different name evolves. Of course these details are up to CLDR.
How about this idea?
1. CLDR puts out a new version or patch today that outputs the name "Pacific Time" for America/Vancouver timestamps starting March 9, regardless of whether the tm_isdst flag is 1 or 0 for those timestamps. The idea is that this new CLDR version will work for America/Vancouver regardless of whether the associated TZDB version is 2026a or 2026b. The spelling of the string "Pacific Time" is entirely up to you; if you prefer "Pacific Daylight Time" then by all means use that.
2. TZDB puts out a release 2026b today that changes tm_isdst to 0.
3. Downstream users are advised to update CLDR if they update TZDB.
Would that work for you? Quite possibly the "today" is a bit fast but the point is that we should not wait for months to get going on this. The ship is sailing Monday, not in November. Putting things off is not a good strategy.
I'm also interested in which legislation you saw that says this change to "Pacific Time" happens at midnight on Monday?
The name "Pacific Time" is specified by the Interpretation Amendment Act, 2019, SBC 2019, c 41 <https://canlii.ca/t/55ht0>. That act comes into force on Monday, March 9 by BC Order In Council 36/2026 <https://www.bclaws.gov.bc.ca/civix/document/id/oic/oic_cur/0063_2026>. The OIC does not specify time of day, which means it comes into force at the start of the day; see < https://www.bclaws.gov.bc.ca/civix/document/id/consol15/consol15/00_96238_01...
.
Mark Davis wrote:
Using the name "Pacific Time" for both a fixed time and one that observes daylight savings will clearly cause confusion among people all over the US and Canada (and beyond).
And the best way to cause even greater confusion is for the new name “Pacific Time” to refer to UTC-7.
if the tm_isdst flag is flipped, people will see "Pacific Daylight Time".
I wonder if that is exactly what some folks want, particularly those who are selling this as “permanent daylight saving time” instead of permanent standard time with a different UTC offset, which is what it really is. -- Doug Ewell, CC, ALB | Lakewood, CO, US | ewellic.org
On 2026-03-06 15:26, Mark Davis Ⓤ wrote:
1. CLDR (and the software that uses it) does not use the TZDB abbreviations at all; it only depends on the timezone ID, and the offsets & tm_isdst flags produced by the TZDB rules.
It also can depend on the timestamp (the number of seconds since 1970), right? For example, given TZ = "Pacific/Guam", UT offset = +10 hours, and tm_isdst = 0, then the string can be "Chamorro Standard Time" for today's timestamps, and also be "Guam Standard Time" for timestamps in 1999. See <https://github.com/unicode-org/cldr/blob/edc66fb4354f8ee6debbcf94faeb5496b38...>. So if I'm right, CLDR could be changed to output "Pacific Time" (or a translation) for all America/Vancouver timestamps that occur after Monday. I.e., that's *technically* feasible regardless of whether it's a good idea.
The first of those formats is "Generic non-location format", like "Pacific Time". A meeting that happens at "13:00 Pacific Time" means that it happens at different UTC times during the summer and winter; it is driven by the wall time in a metazone spanning the multiple timezone IDs that use something called "Pacific Time".
Thanks, I see that problem now: "Pacific Time" has long had one meaning to CLDR, and starting Monday that meaning will disagree with the meaning for "Pacific Time" in the British Columbia legislation. In some sense this means CLDR has a *different* beef with the BC legislation than TZDB does. TZDB can't handle two-letter abbreviations so "PT" is out and the PST/PDT abbreviations are confusing so we're thinking of penciling in "MST" for now. In contrast, CLDR users and software might get confused by "Pacific Time" meaning one thing for time in BC and another thing for time in scheduling software, and I can see why CLDR doesn't have anything yet penciled in to fix that.
The best we could probably do is advise all products using CLDR directly or indirectly to either not update to the TDBC data release, or to patch the tm_isdst flag.
OK, but I'm a bit puzzled about the details here. Robert wrote that CLDR was planning to ship a patched copy of TZDB in ICU. If so, what's the problem with changing TZDB along the lines already suggested? Even with such a change, CLDR users will see patched TZDB data, and then CLDR can decide on its own schedule how to resolve the "Pacific Time" mess, and once it does that it can go back to shipping an unmodified copy of TZDB.
4. The population of people living in the region covered by America/Vancouver is roughly 100 times the population of Yukon; so an approach taken for the latter doesn't necessarily scale to the former.
By "scale" here I assume you mean human scale, not implementation scale. That is, even though we could do America/Vancouver the same way we did America/Whitehorse, when we can't make everybody happy (as is the case with this kind of change) then the bigger the population, the more likely we'll get complaints.
On Fri, Mar 6, 2026 at 4:32 PM Paul Eggert <eggert@cs.ucla.edu> wrote:
On 2026-03-06 15:26, Mark Davis Ⓤ wrote:
1. CLDR (and the software that uses it) does not use the TZDB abbreviations at all; it only depends on the timezone ID, and the offsets & tm_isdst flags produced by the TZDB rules.
It also can depend on the timestamp (the number of seconds since 1970), right? For example, given TZ = "Pacific/Guam", UT offset = +10 hours, and tm_isdst = 0, then the string can be "Chamorro Standard Time" for today's timestamps, and also be "Guam Standard Time" for timestamps in 1999. See < https://github.com/unicode-org/cldr/blob/edc66fb4354f8ee6debbcf94faeb5496b38...
.
Yes, of course. So if I'm right, CLDR could be changed to output "Pacific Time" (or a
translation) for all America/Vancouver timestamps that occur after Monday. I.e., that's *technically* feasible regardless of whether it's a good idea.
It can be changed, *but not by* Monday. And changes to software that uses CLDR (including but not limited to ICU) will take far longer. (One of the choices we are looking at is to insulate CLDR more from changes in the TZDB, which won't help the BC situation, but could help in the future.)
The first
of those formats is "Generic non-location format", like "Pacific Time". A meeting that happens at "13:00 Pacific Time" means that it happens at different UTC times during the summer and winter; it is driven by the wall time in a metazone spanning the multiple timezone IDs that use something called "Pacific Time".
Thanks, I see that problem now: "Pacific Time" has long had one meaning to CLDR, and starting Monday that meaning will disagree with the meaning for "Pacific Time" in the British Columbia legislation.
In some sense this means CLDR has a *different* beef with the BC legislation than TZDB does.
Yes, exactly. The fundamental problem is because of the suddenness of BC's decision. It would however help us (and lead to less confusion for potentially many millions of users) if the decision to issue a change for this in the TZDB were somewhat delayed.
TZDB can't handle two-letter abbreviations so "PT" is out and the PST/PDT abbreviations are confusing so we're thinking of penciling in "MST" for now. In contrast, CLDR users and software might get confused by "Pacific Time" meaning one thing for time in BC and another thing for time in scheduling software, and I can see why CLDR doesn't have anything yet penciled in to fix that.
The best we could probably do is advise all products using CLDR directly or indirectly to either not update to the TDBC data release, or to patch the tm_isdst flag.
OK, but I'm a bit puzzled about the details here. Robert wrote that CLDR was planning to ship a patched copy of TZDB in ICU. If so, what's the problem with changing TZDB along the lines already suggested? Even with such a change, CLDR users will see patched TZDB data, and then CLDR can decide on its own schedule how to resolve the "Pacific Time" mess, and once it does that it can go back to shipping an unmodified copy of TZDB.
ICU is not the only software that uses CLDR, and not every product using ICU will upgrade immediately to a dot version of it. We may wish it otherwise, but sometimes the gears turn slowly. So a delay would be beneficial.
4. The population of people living in the region covered by
America/Vancouver is roughly 100 times the population of Yukon; so an approach taken for the latter doesn't necessarily scale to the former.
By "scale" here I assume you mean human scale, not implementation scale. That is, even though we could do America/Vancouver the same way we did America/Whitehorse, when we can't make everybody happy (as is the case with this kind of change) then the bigger the population, the more likely we'll get complaints.
I'm not worried about the volume of complaints; I'm worried about a large number of users being confused or misled.
On Fri, 6 Mar 2026 at 17:01, Robert Bastian via tz <tz@iana.org> wrote:
All that ICU sees is tm_isdst=0.
If that is true, then that is an extremely brittle design decision in the face of outright zone changes — one which needs some re-evaluation regardless of the proximal situation or how it is resolved. While I admit that whether the bulk of British Columbia is truly "changing zones" here is dependent on one's interpretation, it seems readily apparent to me that "friendly names" such as those provided by CLDR should *at least* be keyed on TZID and *calculated UTC offset* (with reasonable fallbacks) to ensure they don't break if and when a true zone change occurs. The vagaries of the obsolescent tm_isdst flag needn't factor into this equation.
I'm also interested in which legislation you saw that says this change to "Pacific Time" happens at midnight on Monday?
The Order in Council effectuates the legislative changes from Monday 9 March 2026. https://www.bclaws.gov.bc.ca/civix/document/id/oic/oic_cur/0063_2026 So, legally, the change from 02:00 Pacific Standard Time to 03:00 Pacific Daylight Time occurs as usual on Sunday, and the new legal name for the zone takes effect 21 hours later at the start of the day on Monday along with the repeal of BC's legal framework for DST. This is a strong reason for modeling the data as we presently have it drafted. I note that we initially took the exact same approach in tzdata for Yukon in 2020 (albeit mistakenly at first). We had (incorrectly) understood that the Yukon press release published 2020-03-04 described a "done deal" effective 2020-03-08. While we did not rush to release then, as wall clock times would not diverge until 2020-11-01, release 2020a, dated 2020-04-23, reflected our then-understanding of Yukon's change and published MST with tm_isdst=0. We later found out that the change wouldn't actually take legal effect until 2020-11-01, so release 2020b, dated 2020-10-06, retroactively applied PDT and tm_isdst=1 back to the 2020 DST period until the 2020-11-01 change. https://mm.icann.org/pipermail/tz/2020-July/029161.html https://mm.icann.org/pipermail/tz/2020-September/029281.html https://mm.icann.org/pipermail/tz/2020-September/054318.html So, a system taking tzdata updates promptly would have seen the following for America/Whitehorse in 2020: - To start the year: UTC−8, PST, tm_isdst=0 - From 2020-03-08: UTC−7, PDT, tm_isdst=1 - From ≥2020-04-23 (2020a update): UTC−7, MST, tm_isdst=0 - From ≥2020-10-06 (2020b update): UTC−7, PDT, tm_isdst=1 - From 2020-11-01: UTC−7, MST, tm_isdst=0 All of this back-and-forth with tm_isdst transpired without issues being raised at the time. -- Tim Parenti
CLDR tries to match common usage, and common usage of "Mountain Standard Time" for UTC-7 in BC has just not been demonstrated.
I assume you meant "in America/Vancouver" not "in BC", as "Mountain Standard Time" has long been common usage in some parts of eastern BC.
Either really. The share of the BC population that is currently on MST is tiny, it doesn't shift the scale for "common usage".
Unfortunately if we wait for common usage to be demonstrated for the Vancouver area we'll have to wait for months, and for reasons I hope are obvious we shouldn't do that - certainly not until November.
These reasons are not obvious to me. We have a perfectly good name that we can continue using until November.
We have a law and a press release from the BC Attorney General's office saying "Pacific Time".
The press release also says things like "People and businesses will have eight months to prepare for Nov. 1, 2026, when clocks would usually be turned back, but now will remain the same. At that point, the transition to Pacific time, the name of B.C.’s new time zone, will be complete." I get that TZDB puts a lot of value on following some law to the letter, but the BC government has explicitly announced this summer as a transionary period, so I don't understand why you have to release this change 5 days later if a major library is telling you that this will break them.
So my guess is that CLDR will go with "Pacific Time" for now, and then change later if a different name evolves. Of course these details are up to CLDR.
I think I have explained in detail what CLDR is doing and why.
1. CLDR puts out a new version or patch today 2. TZDB puts out a release 2026b today that changes tm_isdst to 0. 3. Downstream users are advised to update CLDR if they update TZDB.
That's not feasible. TZDB updates are basically immediate in most major systems, whereas CLDR/ICU updates take weeks, if not months, to propagate to devices.
If that is true, then that is an extremely brittle design decision in the face of outright zone changes — one which needs some re-evaluation regardless of the proximal situation or how it is resolved.
It is, and Unicode's next-gen library, ICU4X, whose timezone code was mostly my design, does not do this and won't break. However, ICU puts a lot of value on backwards compatibility, i.e. updating timezone data for old libraries, which is why this is a very hard issue to fix, and it "mostly works", because we usually get more than a week's notice for such an impactful change.
I note that we initially took the exact same approach in tzdata for Yukon in 2020 All of this back-and-forth with tm_isdst transpired without issues being raised at the time.
I was not working at Unicode in 2020, so I don't know exactly how this was handled. I know, however, that we used "Yukon Standard Time" as requested by the Yukon government, for which we luckily already had translations for the pre-1984 zone, and which does depend on tm_isdst. I'm sure this was a lot of work for us regardless, and it might have even broken users – keep in mind that the population we're talking about this week is 100x that of the Yukon. In the end, I can't make you do anything. We decided that we should ask you to take this into consideration, but that seems to have failed. I have better things to do with my weekend (Europe/Zurich here), so thank you for your time, and we will go with option 2, which is to ship a patched TZDB in ICU. On Fri, 6 Mar 2026 at 23:38, Tim Parenti <tim@timtimeonline.com> wrote:
On Fri, 6 Mar 2026 at 17:01, Robert Bastian via tz <tz@iana.org> wrote:
All that ICU sees is tm_isdst=0.
If that is true, then that is an extremely brittle design decision in the face of outright zone changes — one which needs some re-evaluation regardless of the proximal situation or how it is resolved.
While I admit that whether the bulk of British Columbia is truly "changing zones" here is dependent on one's interpretation, it seems readily apparent to me that "friendly names" such as those provided by CLDR should *at least* be keyed on TZID and *calculated UTC offset* (with reasonable fallbacks) to ensure they don't break if and when a true zone change occurs. The vagaries of the obsolescent tm_isdst flag needn't factor into this equation.
I'm also interested in which legislation you saw that says this change to "Pacific Time" happens at midnight on Monday?
The Order in Council effectuates the legislative changes from Monday 9 March 2026. https://www.bclaws.gov.bc.ca/civix/document/id/oic/oic_cur/0063_2026 So, legally, the change from 02:00 Pacific Standard Time to 03:00 Pacific Daylight Time occurs as usual on Sunday, and the new legal name for the zone takes effect 21 hours later at the start of the day on Monday along with the repeal of BC's legal framework for DST. This is a strong reason for modeling the data as we presently have it drafted.
I note that we initially took the exact same approach in tzdata for Yukon in 2020 (albeit mistakenly at first). We had (incorrectly) understood that the Yukon press release published 2020-03-04 described a "done deal" effective 2020-03-08. While we did not rush to release then, as wall clock times would not diverge until 2020-11-01, release 2020a, dated 2020-04-23, reflected our then-understanding of Yukon's change and published MST with tm_isdst=0. We later found out that the change wouldn't actually take legal effect until 2020-11-01, so release 2020b, dated 2020-10-06, retroactively applied PDT and tm_isdst=1 back to the 2020 DST period until the 2020-11-01 change. https://mm.icann.org/pipermail/tz/2020-July/029161.html https://mm.icann.org/pipermail/tz/2020-September/029281.html https://mm.icann.org/pipermail/tz/2020-September/054318.html
So, a system taking tzdata updates promptly would have seen the following for America/Whitehorse in 2020:
- To start the year: UTC−8, PST, tm_isdst=0 - From 2020-03-08: UTC−7, PDT, tm_isdst=1 - From ≥2020-04-23 (2020a update): UTC−7, MST, tm_isdst=0 - From ≥2020-10-06 (2020b update): UTC−7, PDT, tm_isdst=1 - From 2020-11-01: UTC−7, MST, tm_isdst=0
All of this back-and-forth with tm_isdst transpired without issues being raised at the time.
-- Tim Parenti
On 2026-03-06 15:04, Robert Bastian wrote:
TZDB updates are basically immediate in most major systems
They are not immediate for many of the systems I use. It can take many months, particularly with devices that are not networked or that are maintained only fitfully by their suppliers. The TZDB project asks for at least a year's notice for this sort of thing because updates can take quite a while to percolate downstream. We don't need to release a new TZDB today. But we should not target months from now. We should get this done soon.
I get that TZDB puts a lot of value on following some law to the letter, but the BC government has explicitly announced this summer as a transionary period, so I don't understand why you have to release this change 5 days later if a major library is telling you that this will break them.
I don't see a major breakage here. If I understand things correctly, America/Vancouver people combining older CLDR with newer TZDB would see "Pacific Standard Time" instead of the legally-specified "Pacific Time". Although infelicitous to experts, that string isn't "broken": it's close enough to the real thing for most users, and only time pedants and maybe politicians will care. Though I'm still a bit confused by this, as you mentioned that CLDR is planning to patch the copy of TZDB that it contains, in which case such a combination won't occur and the issue is moot for now (though of course we'd like to remove the need for any such patch later on, as CLDR's schedule permits). Or are you referring to Mark's point that "Pacific Time" in many user interfaces means "Pacific Standard Time or Pacific Daylight Time, depending on the time of year", and that it's confusing if "Pacific Time" also means time in British Columbia? If so, I can see that this is a pain but there are surely other ambiguous phrases in CLDR and user interfaces don't collapse because of them. (Of course this is an issue for CLDR to decide; TZDB doesn't need to worry about those long strings.)
On 2026-03-06 11:39, Paul Eggert via tz wrote:
On 2026-03-06 08:11, Robert Bastian via tz wrote:
Because CLDR keys its display names by this flag, this change will cause ICU and other downstream software (including major operating systems) to display BC’s UTC-7 as "Pacific Standard Time," while Los Angeles’ UTC-7 will display as "Pacific Daylight Time."
Maintenance releases of ICU 78.3 and CLDR 48.2 are scheduled for this month, so it seems unlikely that anythng to do with these changes could make it in. Major releases ICU 79 and CLDR 49 are planned for October and could incorporate changes required, including those to TZ DB.
Yes, and what's currently in the draft TZDB on GitHub (America/Vancouver switching to abbreviation "-07") was intended to be merely a placeholder. We weren't intending to publish it as 2026b.
For the reason you mention and for other software-compatibility reasons, let's change the "-07" placeholder to an alphabetic abbreviation. The simplest fix appears to be to change to the abbreviation "MST", as is already the case for America/Vancouver's geographic neighbors that observe UTC-7 all year. This should fix the CLDR issue (albeit in a different way than what you suggested), and should be good enough until the BC government and/or common practice advises us all later on what three-or-more-character abbreviation is most popular.
Of course we'd prefer to make just one change now, and no changes later, but it seems we do not have that luxury given the rushed way this was done legally. And I would rather publish something before the actual legal change occurs on Monday, rather than issue a post-facto change.
That would likely be a divergence from the expectation and requirement that time remains P[D]T, until other libraries and systems have a chance to catch up for November, and only then will any change in time zone be obvious, especially as most devices (phones) will then show MST, compatible with Yukon and eastern BC regions following AB time, rather than PT or anything similar. ISTM that if you want enable apps and systems to display anything other than TZ DB ids, you have to allow adequate time for those changes to be planned, implemented, and distributed, when possible. Otherwise you will be encouraging downstreams to use the TZ DB ids to provide quick results, with possibly consequent flurries of complaints from downstreams, users, and demands from irate politicians and provincial government officials, who ignored the requirement for adequate prior notice and consultation with the local/summer time keeping global community on here. I would also urge Alberta politicians, who are once again talking about pushing our time zone further east, or who knows what may be in their tiny minds this time, to have provincial government officials get in touch here for guidance, before the October referendum, on which they are now talking about including a question about the summer time issue. Otherwise they risk any ill considered ideas being ignored, and popping up on their phones different from their plans, as appears likely with BC time. -- 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 à retrancher but when there is no more to cut -- Antoine de Saint-Exupéry
After reviewing this thread's discussion, the consensus is to delay the tm_isdst transition as requested, so I installed the attached proposed further patch after talking with Tim. This patch contains a temporary workaround for America/Vancouver timestamps between March 9 and November 1 of this year. The workaround should accommodate CLDR's current limitation, by marking these timestamps with tm_isdst as requested. The plan is to remove the temporary workaround once CLDR is updated to remove the limitation, which as I understand it can be done by a CLDR release before November. Although not affecting CLDR, this patch also replaces the "-07" placeholder abbreviation with "MST". No abbreviation choice is ideal here, but "MST" appears to be the best of a bad lot. This abbreviation can be updated once we find out what common practice does with three-or-more-letter abbreviations. This patch removes any need for a TZDB release in the next couple of days, as TZDB's proposed March 9 entry is now effectively a no-op and there is no user-visible change in America/Vancouver's behavior until November. However, we do need a new TZDB release sooner rather than later because that November change must be user-visible, and TZDB changes can take time to propagate to devices regardless of whether the devices also use CLDR. So I'm thinking we wait for further comments and release TZDB 2026b in a couple of weeks, or April at the latest - unless some unrelated and more urgent data change comes up, in case we can simply release. This episode is a bit of a wakeup call for the coordination between TZDB and CLDR. Although in the past we've lucked out with similar changes in Yukon and elsewhere, we will likely not be so lucky in plausible future changes to timekeeping in North America, the EU, and other places where people are considering abolishing DST transitions and changing time zones and time zone names. Yesterday's email from Brian Inglis[1] suggested that CLDR won't be able to accommodate the America/Vancouver change until October, but I hope that's overly pessimistic as it will surely take considerable time for the CLDR change's effects to be shaken out in applications, and users will need to deal with timestamps planned for November and later well before November rolls around. In short, the process for updating TZDB + CLDR surely can use more streamlining. [1]: https://lists.iana.org/hyperkitty/list/tz@iana.org/message/BRP7ONFZU42SFR4TN...
Thanks to all involved! The more of a delay the better on the one hand, but it is also clear that it has to be done *well* before November or even more serious problems would happen. The extra time will allow us to figure out the best approaches both long-term and short-term, and give clients more time to adjust their implementations. I agree that more cooperation between CLDR and the TZDB groups would be very positive for the billions of people who are affected by both. While the vast majority of changes on both sides don't cause problems, there are definitely hard cases that pop up where additional communication would avoid problems. We both get hammered by governments that take precipitous actions without understanding the consequences! We'll try to keep you updated on what goes on in CLDR as this one plays out. Mark On Sat, Mar 7, 2026 at 2:00 PM Paul Eggert via tz <tz@iana.org> wrote:
After reviewing this thread's discussion, the consensus is to delay the tm_isdst transition as requested, so I installed the attached proposed further patch after talking with Tim. This patch contains a temporary workaround for America/Vancouver timestamps between March 9 and November 1 of this year. The workaround should accommodate CLDR's current limitation, by marking these timestamps with tm_isdst as requested. The plan is to remove the temporary workaround once CLDR is updated to remove the limitation, which as I understand it can be done by a CLDR release before November.
Although not affecting CLDR, this patch also replaces the "-07" placeholder abbreviation with "MST". No abbreviation choice is ideal here, but "MST" appears to be the best of a bad lot. This abbreviation can be updated once we find out what common practice does with three-or-more-letter abbreviations.
This patch removes any need for a TZDB release in the next couple of days, as TZDB's proposed March 9 entry is now effectively a no-op and there is no user-visible change in America/Vancouver's behavior until November. However, we do need a new TZDB release sooner rather than later because that November change must be user-visible, and TZDB changes can take time to propagate to devices regardless of whether the devices also use CLDR. So I'm thinking we wait for further comments and release TZDB 2026b in a couple of weeks, or April at the latest - unless some unrelated and more urgent data change comes up, in case we can simply release.
This episode is a bit of a wakeup call for the coordination between TZDB and CLDR. Although in the past we've lucked out with similar changes in Yukon and elsewhere, we will likely not be so lucky in plausible future changes to timekeeping in North America, the EU, and other places where people are considering abolishing DST transitions and changing time zones and time zone names. Yesterday's email from Brian Inglis[1] suggested that CLDR won't be able to accommodate the America/Vancouver change until October, but I hope that's overly pessimistic as it will surely take considerable time for the CLDR change's effects to be shaken out in applications, and users will need to deal with timestamps planned for November and later well before November rolls around.
In short, the process for updating TZDB + CLDR surely can use more streamlining.
[1]:
https://lists.iana.org/hyperkitty/list/tz@iana.org/message/BRP7ONFZU42SFR4TN...
Paul Eggert via tz <tz@iana.org> writes:
After reviewing this thread's discussion, the consensus is to delay the tm_isdst transition as requested, so I installed the attached proposed further patch after talking with Tim. [...]
Will there be a 2026b with this change in the immediate future? DES -- Dag-Erling Smørgrav - des@des.no
On Sun, 8 Mar 2026 at 07:43, Dag-Erling Smørgrav via tz <tz@iana.org> wrote:
Paul Eggert via tz <tz@iana.org> writes:
After reviewing this thread's discussion, the consensus is to delay the tm_isdst transition as requested, so I installed the attached proposed further patch after talking with Tim. [...]
Will there be a 2026b with this change in the immediate future?
Not "immediate", but soon; see Paul's remarks further down that same message: On Sat, 7 Mar 2026 at 17:00, Paul Eggert via tz <tz@iana.org> wrote:
This patch removes any need for a TZDB release in the next couple of days, as TZDB's proposed March 9 entry is now effectively a no-op and there is no user-visible change in America/Vancouver's behavior until November. However, we do need a new TZDB release sooner rather than later because that November change must be user-visible, and TZDB changes can take time to propagate to devices regardless of whether the devices also use CLDR. So I'm thinking we wait for further comments and release TZDB 2026b in a couple of weeks, or April at the latest - unless some unrelated and more urgent data change comes up, in case we can simply release.
In short, the temporary workaround affords us a bit more time for pre-coordination to gain better confidence on whether "MST" will be suitable in the longer term before we release it, with the goal of minimizing the risk of needing a re-release for further fixes later. On Sun, 8 Mar 2026 at 00:08, Mark Davis Ⓤ via tz <tz@iana.org> wrote:
Thanks to all involved! The more of a delay the better on the one hand, but it is also clear that it has to be done *well* before November or even more serious problems would happen.
The extra time will allow us to figure out the best approaches both long-term and short-term, and give clients more time to adjust their implementations.
Thank you for your understanding. Paul had earlier alluded to the "obvious reasons" of the "more serious problems" caused by waiting too long: People and applications that schedule things like meetings into the future may not care too much about November now, *but they will not wait until November to do so*. While this temporary workaround hacking the tm_isdst bit allows us to press pause on an imminent release for tzdata, the upcoming changes to scheduled UTC offsets do, at the very least, need to start becoming visible to end-users *much closer* to now than to then. Planning to release in a few weeks, closer to the end of the current "silly season", I think, ought to strike that balance about as well as can be managed without knowing in advance what else may arise. We ask for long leadtime not so we can sit on changes, but so we can be as thoughtful as possible about when and how we release them. While I understand the BC Council's apparent inclination to "get things done with" and bring the legislation into official effect from tomorrow, I find it interesting there would have been no practical difference to the Order in Council providing an effective date of 2026-10-31 or even 2026-11-01 instead, more similar to how Yukon implemented their change in 2020. Alas. BC's change has been part of the usual semi-annual DST discussion across North American media this cycle, along with similar latent "trigger legislation" across the continent. So perhaps this may caution other jurisdictions to think carefully about these sorts of details should they choose to move forward. -- Tim Parenti
On Sat, 7 Mar 2026 at 17:00, Paul Eggert via tz <tz@iana.org> wrote:
This episode is a bit of a wakeup call for the coordination between TZDB and CLDR. Although in the past we've lucked out with similar changes in Yukon and elsewhere, we will likely not be so lucky in plausible future changes to timekeeping in North America, the EU, and other places where people are considering abolishing DST transitions and changing time zones and time zone names.
I agree. I understand since there is a lot of translation work involved, the roughly-twice-a-year release cadence for CLDR and ICU is not likely to change. It seems to me, then, that both projects ought to aim toward being more resilient to sudden, unexpected changes in TZDB data, especially given those release dates' apparent proximity to the typical "silly seasons" within the timekeeping world. We can certainly do our part, as well, in helping to smooth over some rough edges as we have here, but we will not be able to predict everything that might possibly be thrown at us. Our remit remains ensuring wall-clock times can be accurately computed — even in the face of changes where there may no longer be a good display name for it, or a former display name may become otherwise unsuitable. Downstream projects should expect that any assumptions related to actual timekeeping practices are subject to sudden breakage. On Fri, 6 Mar 2026 at 18:27, Mark Davis Ⓤ via tz <tz@iana.org> wrote:
CLDR (and the software that uses it) does not use the TZDB abbreviations at all; it only depends on the timezone ID, and the offsets & tm_isdst flags produced by the TZDB rules.
On Fri, 6 Mar 2026 at 17:01, Robert Bastian via tz <tz@iana.org> wrote:
All that ICU sees is tm_isdst=0. The link between time zones and their "metazone", which determine display names, comes from CLDR.
A potential constructive suggestion here would be improving programmatic checks in software using CLDR in conjunction with tzdata, such as ICU. In particular, it seems wise to shift away from relying solely on the tm_isdst flag (which per RFC 9636 is subject to the specifics of "law or practice"), and to instead include calculated offsets in consideration. For example, if software such as ICU detects that tzdata has calculated an offset which CLDR does not expect for the zone ID in question (that is, one not specified by the currently active "metazone" in CLDR), then the selected "format"/display name could fallback to a reasonable default like "UTC±*N*" in the absence of anything better. *Ex:* Updated tzdata calculates −7 into the indefinite future for America/Vancouver; CLDR already calls this "Pacific Daylight Time" for that zone and so software continues to display that unless/until a more suitable name emerges and a CLDR update is installed to reflect it. (But if tzdata later calculated −9 for some reason, it would fail to "UTC−9".) For greater specificity, one could perhaps trigger this default on unexpected (offset, tm_isdst) tuples instead of just offset. *Ex:* CLDR expects to refer to (−8, 0) as "Pacific Standard Time" and (−7, 1) as "Pacific Daylight Time", but does not yet have a name for (−7, 0) and so software would fail gracefully to "UTC−7" until CLDR can be patched. This could act as a signal to both end-users and developers that *something* has changed (whether an outright offset or the "law or practice" indicated by the flag) and that extra caution should be exercised in the meantime. Whether "anything better" than "UTC±*N*" already exists could maybe be determined, in part, by looking at any inactive/past "metazones" for the zone ID in question, to see whether there is a history of using an older "format"/display name in that region which could suffice until CLDR can more thoroughly review. Those heuristics may get a bit thorny, though, especially as one looks further back — so simpler signals based on calculated offsets likely balance concerns better. -- Tim Parenti
Good points. We had already been considering doing away with depending upon the flag, and you have some other useful suggestions. Our fallback is to drop back to different time zone formats, but it was not as automatic as it should be. On Sun, Mar 8, 2026, 12:05 Tim Parenti <tim@timtimeonline.com> wrote:
On Sat, 7 Mar 2026 at 17:00, Paul Eggert via tz <tz@iana.org> wrote:
This episode is a bit of a wakeup call for the coordination between TZDB and CLDR. Although in the past we've lucked out with similar changes in Yukon and elsewhere, we will likely not be so lucky in plausible future changes to timekeeping in North America, the EU, and other places where people are considering abolishing DST transitions and changing time zones and time zone names.
I agree. I understand since there is a lot of translation work involved, the roughly-twice-a-year release cadence for CLDR and ICU is not likely to change. It seems to me, then, that both projects ought to aim toward being more resilient to sudden, unexpected changes in TZDB data, especially given those release dates' apparent proximity to the typical "silly seasons" within the timekeeping world.
We can certainly do our part, as well, in helping to smooth over some rough edges as we have here, but we will not be able to predict everything that might possibly be thrown at us. Our remit remains ensuring wall-clock times can be accurately computed — even in the face of changes where there may no longer be a good display name for it, or a former display name may become otherwise unsuitable. Downstream projects should expect that any assumptions related to actual timekeeping practices are subject to sudden breakage.
On Fri, 6 Mar 2026 at 18:27, Mark Davis Ⓤ via tz <tz@iana.org> wrote:
CLDR (and the software that uses it) does not use the TZDB abbreviations at all; it only depends on the timezone ID, and the offsets & tm_isdst flags produced by the TZDB rules.
On Fri, 6 Mar 2026 at 17:01, Robert Bastian via tz <tz@iana.org> wrote:
All that ICU sees is tm_isdst=0. The link between time zones and their "metazone", which determine display names, comes from CLDR.
A potential constructive suggestion here would be improving programmatic checks in software using CLDR in conjunction with tzdata, such as ICU. In particular, it seems wise to shift away from relying solely on the tm_isdst flag (which per RFC 9636 is subject to the specifics of "law or practice"), and to instead include calculated offsets in consideration.
For example, if software such as ICU detects that tzdata has calculated an offset which CLDR does not expect for the zone ID in question (that is, one not specified by the currently active "metazone" in CLDR), then the selected "format"/display name could fallback to a reasonable default like "UTC±*N*" in the absence of anything better. *Ex:* Updated tzdata calculates −7 into the indefinite future for America/Vancouver; CLDR already calls this "Pacific Daylight Time" for that zone and so software continues to display that unless/until a more suitable name emerges and a CLDR update is installed to reflect it. (But if tzdata later calculated −9 for some reason, it would fail to "UTC−9".)
For greater specificity, one could perhaps trigger this default on unexpected (offset, tm_isdst) tuples instead of just offset. *Ex:* CLDR expects to refer to (−8, 0) as "Pacific Standard Time" and (−7, 1) as "Pacific Daylight Time", but does not yet have a name for (−7, 0) and so software would fail gracefully to "UTC−7" until CLDR can be patched. This could act as a signal to both end-users and developers that *something* has changed (whether an outright offset or the "law or practice" indicated by the flag) and that extra caution should be exercised in the meantime.
Whether "anything better" than "UTC±*N*" already exists could maybe be determined, in part, by looking at any inactive/past "metazones" for the zone ID in question, to see whether there is a history of using an older "format"/display name in that region which could suffice until CLDR can more thoroughly review. Those heuristics may get a bit thorny, though, especially as one looks further back — so simpler signals based on calculated offsets likely balance concerns better.
-- Tim Parenti
OK, but I'm a bit puzzled about the details here. Robert wrote that CLDR was planning to ship a patched copy of TZDB in ICU. If so, what's the problem with changing TZDB along the lines already suggested? Even with such a change, CLDR users will see patched TZDB data, and then CLDR can decide on its own schedule how to resolve the "Pacific Time" mess, and once it does that it can go back to shipping an unmodified copy of TZDB.
This will fix the issue for Android and Chrome, which use ICU's internal TZDB instead of the system's for formatting. I have no idea if this fix would work for other systems.
They are not immediate for many of the systems I use. It can take many months, particularly with devices that are not networked or that are maintained only fitfully by their suppliers.
While there are certainly devices where the updates take months, the primary devices that billions of users interact with every day (Android, iOS, macOS, mainstream Linux distributions) update in a matter of days.
I don't see a major breakage here. If I understand things correctly, America/Vancouver people combining older CLDR with newer TZDB would see "Pacific Standard Time" instead of the legally-specified "Pacific Time". Although infelicitous to experts, that string isn't "broken": it's close enough to the real thing for most users, and only time pedants and maybe politicians will care.
It could be argued that Pacific Standard Time is correct now. However, there are certainly users who are aware of the difference between Pacific Daylight Time and Pacific Standard Time. The broader issue is also that America/Los_Angeles will use "Pacific Daylight Time" for UTC-7 this summer, so if Vancouver uses "Pacific Standard Time", to a user that is a strong indication that those are different offsets (in all other cases, "standard" != "daylight"). This matters in scenarios where both time zones are present, such as with time zone pickers, TV schedules, meetings, travel between the time zones, etc.
A potential constructive suggestion here would be improving programmatic checks in software using CLDR in conjunction with tzdata, such as ICU. In particular, it seems wise to shift away from relying solely on the tm_isdst flag (which per RFC 9636 is subject to the specifics of "law or practice"), and to instead include calculated offsets in consideration.
I think the reason why CLDR hasn't associated "metazones" with offsets was to reduce the amount of churn and required releases. The same name can be used for different offsets at different times: "Yakutsk Time" meant UTC+10 before 2014 and UTC+9 since then, but the 2014 TZDB update didn't require a CLDR update, because that string just changed meaning (well, it always meant "the time in Yakutsk"). Similarly, if the US west coast had announced permanent UTC-7 last week as well, we wouldn't have to change anything in CLDR, all those zones could keep using "Pacific Time", which would now just mean something else. So there is a balance to be kept wrt the amount of information that we track in CLDR (we certainly don't want to maintain our own time zone database). We have, in fact, added explicit metazone offsets to the CLDR data model in the last version, but so far only used them for some zones where the tm_isdst value from TZDB doesn't agree with our model of what a daylight saving time is (Europe/Dublin <https://github.com/unicode-org/cldr/blob/b6da18d9b205a9169f85375a0de1b69668a...>, Africa/Windhoek <https://github.com/unicode-org/cldr/blob/b6da18d9b205a9169f85375a0de1b69668a...>). The long term goal is to not require rearguard data anymore, but the cost of course is that we have to maintain these offsets. However, using this data has currently only been implemented in the new ICU4X library, where we're not restricted by ICU's data backward compatibility.
The workaround should accommodate CLDR's current limitation, by marking these timestamps with tm_isdst as requested. The plan is to remove the temporary workaround once CLDR is updated to remove the limitation, which as I understand it can be done by a CLDR release before November.
I'm not thrilled by the plan to retroactively revert the flag again, because then we either have to keep patching the TZDB for this summer anyway, or users will get different display names depending on their TZDB version. But this fixes the immediate issue for us and we can work on solutions in ICU.
This episode is a bit of a wakeup call for the coordination between TZDB and CLDR. Although in the past we've lucked out with similar changes in Yukon and elsewhere
This does not seem to be the first TZDB/CLDR issue of this nature. In 2018 the change to Dublin's tm_isdst would have broken ICU (and other consumers afaict) as it would have flipped the summer/winter display names. The solution back then was to create the rearguard format, which ICU/CLDR require to this day, and which some major platforms ship, potentially in part because of ICU. Maybe the takeaway here should be that changes to tm_isdst are as disruptive to CLDR as changes to offsets, so ideally should be done with some lead time. On Sun, 8 Mar 2026 at 23:46, Mark Davis Ⓤ <mark@unicode.org> wrote:
Good points.
We had already been considering doing away with depending upon the flag, and you have some other useful suggestions.
Our fallback is to drop back to different time zone formats, but it was not as automatic as it should be.
On Sun, Mar 8, 2026, 12:05 Tim Parenti <tim@timtimeonline.com> wrote:
On Sat, 7 Mar 2026 at 17:00, Paul Eggert via tz <tz@iana.org> wrote:
This episode is a bit of a wakeup call for the coordination between TZDB and CLDR. Although in the past we've lucked out with similar changes in Yukon and elsewhere, we will likely not be so lucky in plausible future changes to timekeeping in North America, the EU, and other places where people are considering abolishing DST transitions and changing time zones and time zone names.
I agree. I understand since there is a lot of translation work involved, the roughly-twice-a-year release cadence for CLDR and ICU is not likely to change. It seems to me, then, that both projects ought to aim toward being more resilient to sudden, unexpected changes in TZDB data, especially given those release dates' apparent proximity to the typical "silly seasons" within the timekeeping world.
We can certainly do our part, as well, in helping to smooth over some rough edges as we have here, but we will not be able to predict everything that might possibly be thrown at us. Our remit remains ensuring wall-clock times can be accurately computed — even in the face of changes where there may no longer be a good display name for it, or a former display name may become otherwise unsuitable. Downstream projects should expect that any assumptions related to actual timekeeping practices are subject to sudden breakage.
On Fri, 6 Mar 2026 at 18:27, Mark Davis Ⓤ via tz <tz@iana.org> wrote:
CLDR (and the software that uses it) does not use the TZDB abbreviations at all; it only depends on the timezone ID, and the offsets & tm_isdst flags produced by the TZDB rules.
On Fri, 6 Mar 2026 at 17:01, Robert Bastian via tz <tz@iana.org> wrote:
All that ICU sees is tm_isdst=0. The link between time zones and their "metazone", which determine display names, comes from CLDR.
A potential constructive suggestion here would be improving programmatic checks in software using CLDR in conjunction with tzdata, such as ICU. In particular, it seems wise to shift away from relying solely on the tm_isdst flag (which per RFC 9636 is subject to the specifics of "law or practice"), and to instead include calculated offsets in consideration.
For example, if software such as ICU detects that tzdata has calculated an offset which CLDR does not expect for the zone ID in question (that is, one not specified by the currently active "metazone" in CLDR), then the selected "format"/display name could fallback to a reasonable default like "UTC±*N*" in the absence of anything better. *Ex:* Updated tzdata calculates −7 into the indefinite future for America/Vancouver; CLDR already calls this "Pacific Daylight Time" for that zone and so software continues to display that unless/until a more suitable name emerges and a CLDR update is installed to reflect it. (But if tzdata later calculated −9 for some reason, it would fail to "UTC−9".)
For greater specificity, one could perhaps trigger this default on unexpected (offset, tm_isdst) tuples instead of just offset. *Ex:* CLDR expects to refer to (−8, 0) as "Pacific Standard Time" and (−7, 1) as "Pacific Daylight Time", but does not yet have a name for (−7, 0) and so software would fail gracefully to "UTC−7" until CLDR can be patched. This could act as a signal to both end-users and developers that *something* has changed (whether an outright offset or the "law or practice" indicated by the flag) and that extra caution should be exercised in the meantime.
Whether "anything better" than "UTC±*N*" already exists could maybe be determined, in part, by looking at any inactive/past "metazones" for the zone ID in question, to see whether there is a history of using an older "format"/display name in that region which could suffice until CLDR can more thoroughly review. Those heuristics may get a bit thorny, though, especially as one looks further back — so simpler signals based on calculated offsets likely balance concerns better.
-- Tim Parenti
On 2026-03-09 07:34, Robert Bastian wrote:
America/Los_Angeles will use "Pacific Daylight Time" for UTC-7 this summer, so if Vancouver uses "Pacific Standard Time", to a user that is a strong indication that those are different offsets
But time zone names and abbreviations have never been unambiguous. As Robert alluded to, for years TZDB had "EST" (for "Eastern Standard Time") mean quite different things in Australia and in the US, and though confusing that's what popular usage was. Although we may well may enter an era where time zone names are confusing for a different reason than North America vs Australia, it's not really our job to disambiguate the names. If for some reason "Pacific Time" means one thing in the US and another in Canada, then that may cause problems for users but if those are the names the populace uses then the CLDR architecture should not (and as far as I know does not) insist on a unique string for each such name.
I think the reason why CLDR hasn't associated "metazones" with offsets was to reduce the amount of churn and required releases.
Yes as I'm sure you know, the more CLDR gets into the business of deciding which time zone abbreviations and names should apply, the more churn and releases it will need, because events on the ground can move faster than CLDR's release cycle. Conversely, if CLDR keeps to its longstanding release cycles it will sometimes need to accept minor discrepancies (like "Pacific Standard Time" vs its preferred "Pacific Time") until the next CLDR release.
Maybe the takeaway here should be that changes to tm_isdst are as disruptive to CLDR as changes to offsets, so ideally should be done with some lead time.
For years the TZDB documentation has advised that the tm_isdst flag is almost never needed and its use should be discouraged, with the only plausible-albeit-imperfect exception (mktime) not applying to CLDR's use of the flag. Although understandably this sort of advice can take some time to follow, I hope this thread helps to underscore why the advice was given and why it's significant.
I'm not thrilled by the plan to retroactively revert the flag again
Nor am I. But it would be a mistake for TZDB to leave the flag wrong indefinitely merely because we want to be consistent with TZDB's earlier misrepresentation of the law. TZDB regularly fixes errors in past timestamps, and it will be able to do that even in this unusual case where the temporary error is intentional to accommodate CLDR's temporary limitations. More generally, I hope CLDR follows TZDB's lead in preferring today's names for old timestamps, not yesterday's names. For example, the shell command "TZ=Europe/Berlin date -d '1918-11-11 12:00'" outputs the abbreviation "CET" (for "Central European Time", the current English-language name), not "MEZ" (for "Middle European Zone", the most common English-language name back in 1918). The idea is that TZDB (and I hope CLDR) does not attempt to determine or standardize terminology changes throughout history.
If for some reason "Pacific Time" means one thing in the US and another in Canada, then that may cause problems for users but if those are the names the populace uses then the CLDR architecture should not (and as far as I know does not) insist on a unique string for each such name.
CLDR's names are unique within each format and locale, and ICU has datetime parsing that round trips. Short names are only used where they are commonly understood, e.g. "HNR" is only used in Canadian French, European French uses "UTC-7" in the short format (but "heure normale des Rocheuses" in the long format).
But it would be a mistake for TZDB to leave the flag wrong indefinitely merely because we want to be consistent with TZDB's earlier misrepresentation of the law.
I don't think following the law to the letter should be the ultimate priority, as laws are not written with these technical implications in mind. If the BC government had asked me, I would have told them to make the decree say that the law takes effect on 2026-11-01 – it would have been the same to them, but it seems like that would have forced your hand the other way.
More generally, I hope CLDR follows TZDB's lead in preferring today's names for old timestamps, not yesterday's names. For example, the shell command "TZ=Europe/Berlin date -d '1918-11-11 12:00'" outputs the abbreviation "CET" (for "Central European Time", the current English-language name), not "MEZ" (for "Middle European Zone", the most common English-language name back in 1918). The idea is that TZDB (and I hope CLDR) does not attempt to determine or standardize terminology changes throughout history.
CLDR doesn't have pre-1970 data, so I don't think this is currently a problem. On Mon, 9 Mar 2026 at 21:11, Paul Eggert <eggert@cs.ucla.edu> wrote:
On 2026-03-09 07:34, Robert Bastian wrote:
America/Los_Angeles will use "Pacific Daylight Time" for UTC-7 this summer, so if Vancouver uses "Pacific Standard Time", to a user that is a strong indication that those are different offsets
But time zone names and abbreviations have never been unambiguous. As Robert alluded to, for years TZDB had "EST" (for "Eastern Standard Time") mean quite different things in Australia and in the US, and though confusing that's what popular usage was.
Although we may well may enter an era where time zone names are confusing for a different reason than North America vs Australia, it's not really our job to disambiguate the names. If for some reason "Pacific Time" means one thing in the US and another in Canada, then that may cause problems for users but if those are the names the populace uses then the CLDR architecture should not (and as far as I know does not) insist on a unique string for each such name.
I think the reason why CLDR hasn't associated "metazones" with offsets was to reduce the amount of churn and required releases.
Yes as I'm sure you know, the more CLDR gets into the business of deciding which time zone abbreviations and names should apply, the more churn and releases it will need, because events on the ground can move faster than CLDR's release cycle. Conversely, if CLDR keeps to its longstanding release cycles it will sometimes need to accept minor discrepancies (like "Pacific Standard Time" vs its preferred "Pacific Time") until the next CLDR release.
Maybe the takeaway here should be that changes to tm_isdst are as disruptive to CLDR as changes to offsets, so ideally should be done with some lead time.
For years the TZDB documentation has advised that the tm_isdst flag is almost never needed and its use should be discouraged, with the only plausible-albeit-imperfect exception (mktime) not applying to CLDR's use of the flag. Although understandably this sort of advice can take some time to follow, I hope this thread helps to underscore why the advice was given and why it's significant.
I'm not thrilled by the plan to retroactively revert the flag again
Nor am I. But it would be a mistake for TZDB to leave the flag wrong indefinitely merely because we want to be consistent with TZDB's earlier misrepresentation of the law. TZDB regularly fixes errors in past timestamps, and it will be able to do that even in this unusual case where the temporary error is intentional to accommodate CLDR's temporary limitations.
More generally, I hope CLDR follows TZDB's lead in preferring today's names for old timestamps, not yesterday's names. For example, the shell command "TZ=Europe/Berlin date -d '1918-11-11 12:00'" outputs the abbreviation "CET" (for "Central European Time", the current English-language name), not "MEZ" (for "Middle European Zone", the most common English-language name back in 1918). The idea is that TZDB (and I hope CLDR) does not attempt to determine or standardize terminology changes throughout history.
On Mar 9, 2026, at 2:37 PM, Robert Bastian via tz <tz@iana.org> wrote:
CLDR's names are unique within each format and locale, and ICU has datetime parsing that round trips. Short names are only used where they are commonly understood, e.g. "HNR" is only used in Canadian French, European French uses "UTC-7" in the short format (but "heure normale des Rocheuses" in the long format).
And it has "Australian {Central,Central Western,Eastern,Western} Standard Time", "Australian {Central,Central Western,Eastern,Western} Time", and "Australian {Central,Central Western,Eastern,Western} Daylight Time" for standard time, generic time, and daylight saving time, respectively, for various regions of Australia. (It doesn't provide abbreviations for any of them.)
It does for Australian English: https://github.com/unicode-org/cldr/blob/main/common/main/en_AU.xml#L4964 On Tue, 10 Mar 2026 at 11:10, Guy Harris <gharris@sonic.net> wrote:
On Mar 9, 2026, at 2:37 PM, Robert Bastian via tz <tz@iana.org> wrote:
CLDR's names are unique within each format and locale, and ICU has datetime parsing that round trips. Short names are only used where they are commonly understood, e.g. "HNR" is only used in Canadian French, European French uses "UTC-7" in the short format (but "heure normale des Rocheuses" in the long format).
And it has "Australian {Central,Central Western,Eastern,Western} Standard Time", "Australian {Central,Central Western,Eastern,Western} Time", and "Australian {Central,Central Western,Eastern,Western} Daylight Time" for standard time, generic time, and daylight saving time, respectively, for various regions of Australia. (It doesn't provide abbreviations for any of them.)
On Mar 10, 2026, at 3:32 AM, Robert Bastian <robertbastian@unicode.org> wrote:
It does for Australian English: https://github.com/unicode-org/cldr/blob/main/common/main/en_AU.xml#L4964
And in https://github.com/unicode-org/cldr/blob/main/common/main/en.xml#L4491 as well; what does that do for English in other locales?
There's fallback logic which is fairly involved. en.xml contains the data for American English, hence it has short names for American zones. Most English variants fall back to en_001.xml first, which is "world English" with British spelling (en_GB has country specific data for the United Kingdom, so it shouldn't be in the fallback chain for other countries). en_001 and other locales that fall back to en block the fallback to American short zone names ( https://github.com/unicode-org/cldr/blob/main/common/main/en_001.xml#L983). On Tue, 10 Mar 2026 at 11:42, Guy Harris <gharris@sonic.net> wrote:
On Mar 10, 2026, at 3:32 AM, Robert Bastian <robertbastian@unicode.org> wrote:
It does for Australian English: https://github.com/unicode-org/cldr/blob/main/common/main/en_AU.xml#L4964
And in https://github.com/unicode-org/cldr/blob/main/common/main/en.xml#L4491 as well; what does that do for English in other locales?
A brief note of explanation (since not everyone will have read the spec!) 1. CLDR uses inheritance, so child locales inherit from their parents. Eg fr_CA (French as used in Canada) inherits from fr (French as used in France, = fr_FR) 2. <...>∅∅∅</...> blocks that inheritance for a particular item, meaning that there will be no value for that locale; the reason for doing that is when the item is not generally understood / used in the locale (such as unfamiliar abbreviations). 3. For time zones, when there is no value, an alternative is used (eg UTC-7). 4. en_001 is the ancestor of most English variants. On Tue, Mar 10, 2026 at 8:58 AM Robert Bastian via tz <tz@iana.org> wrote:
There's fallback logic which is fairly involved. en.xml contains the data for American English, hence it has short names for American zones. Most English variants fall back to en_001.xml first, which is "world English" with British spelling (en_GB has country specific data for the United Kingdom, so it shouldn't be in the fallback chain for other countries). en_001 and other locales that fall back to en block the fallback to American short zone names ( https://github.com/unicode-org/cldr/blob/main/common/main/en_001.xml#L983 ).
On Tue, 10 Mar 2026 at 11:42, Guy Harris <gharris@sonic.net> wrote:
On Mar 10, 2026, at 3:32 AM, Robert Bastian <robertbastian@unicode.org> wrote:
It does for Australian English: https://github.com/unicode-org/cldr/blob/main/common/main/en_AU.xml#L4964
And in https://github.com/unicode-org/cldr/blob/main/common/main/en.xml#L4491 as well; what does that do for English in other locales?
On Mar 10, 2026, at 10:01 AM, Mark Davis Ⓤ <mark@unicode.org> wrote:
A brief note of explanation (since not everyone will have read the spec!)
"The spec" presumably being https://unicode.org/reports/tr35/ (and, in particular, https://unicode.org/reports/tr35/#Locale_Inheritance?).
CLDR uses inheritance, so child locales inherit from their parents. Eg fr_CA (French as used in Canada) inherits from fr (French as used in France, = fr_FR) <...>∅∅∅</...> blocks that inheritance for a particular item, meaning that there will be no value for that locale; the reason for doing that is when the item is not generally understood / used in the locale (such as unfamiliar abbreviations). For time zones, when there is no value, an alternative is used (eg UTC-7). en_001 is the ancestor of most English variants. So what is the inheritance hierarchy? Where do en.xml (which, as noted, uses "Australian" in the long names for EST/EDT, CST/CDT, etc. in Australia) and en_001.xml (which says nothing about Australia) sit in that hierarchy?
As for the abbreviations, en_AU.xml has abbreviations that begin with "A", which may make it unique but, as I understand what Robert Elz has said, does not match the abbreviations used in Australia.
You can find it by looking in <parentLocales> here https://github.com/unicode-org/cldr/blob/main/common/supplemental/supplement... Note: English is a lingua franca and inheritance is not specified for all the English locales right now. If inheritance is not specified it will inherit from the parent locale 'en'. Best, Annemarie ~~~~~~~~~~ If you received this communication by mistake, please don't forward it to anyone else, please erase all copies of it, including all attachments, and please let the sender know it went to the wrong person. Thank you! On Tue, Mar 10, 2026 at 12:03 PM Guy Harris via tz <tz@iana.org> wrote:
On Mar 10, 2026, at 10:01 AM, Mark Davis Ⓤ <mark@unicode.org> wrote:
A brief note of explanation (since not everyone will have read the spec!)
"The spec" presumably being https://unicode.org/reports/tr35/ (and, in particular, https://unicode.org/reports/tr35/#Locale_Inheritance?).
1. CLDR uses inheritance, so child locales inherit from their parents. Eg fr_CA (French as used in Canada) inherits from fr (French as used in France, = fr_FR) 2. <...>∅∅∅</...> blocks that inheritance for a particular item, meaning that there will be no value for that locale; the reason for doing that is when the item is not generally understood / used in the locale (such as unfamiliar abbreviations). 3. For time zones, when there is no value, an alternative is used (eg UTC-7). 4. en_001 is the ancestor of most English variants.
So what is the inheritance hierarchy? Where do en.xml (which, as noted, uses "Australian" in the long names for EST/EDT, CST/CDT, etc. in Australia) and en_001.xml (which says nothing about Australia) sit in that hierarchy?
As for the abbreviations, en_AU.xml has abbreviations that begin with "A", which may make it unique but, as I understand what Robert Elz has said, does not match the abbreviations used in Australia.
On 2026-03-09 14:37, Robert Bastian wrote:
If for some reason "Pacific Time" means one thing in the US and another in Canada, then that may cause problems for users but if those are the names the populace uses then the CLDR architecture should not (and as far as I know does not) insist on a unique string for each such name.
CLDR's names are unique within each format and locale
So, assuming there's a genuine dispute between the US and Canada, where "Pacific Time" means one thing north of the border and a different thing south of the border, then I suppose in a Canadian locale CLDR will use the names "Pacific Time" and "US Pacific Time" respectively, whereas in a US locale CLDR will use "Canadian Pacific Time" and "Pacific Time" respectively. Another possibility will be to use the US-centric solution CLDR already uses for Australia, i.e., to use "Canadian Pacific Time" and "Pacific Time" regardless of which English-language locale you're using. Either approach would work technically. Which approach are you leaning towards? More generally, is there a publicly visible discussion thread or bug report about this on the CLDR side that non-CLDRers can follow? <https://cldr.unicode.org/index/downloads> points to <https://unicode-org.atlassian.net/issues/?filter=10837> and to <https://unicode-org.atlassian.net/issues/?filter=10838> but these seem to list only closed issues, whereas I assume this is an open issue.
I don't think following the law to the letter should be the ultimate priority, as laws are not written with these technical implications in mind. If the BC government had asked me
Yeah, they typically don't ask. The BC Attorney General's office didn't even respond to my repeated emails. I expect that their view is that they decide and we implement. And to a great extent they're right.
I would have told them to make the decree say that the law takes effect on 2026-11-01 – it would have been the same to them, but it seems like that would have forced your hand the other way.
Yes, of course if BC had done it the way CLDR wants, TZDB would have done it that way. That's our job. But I disagree that it would have been the same to the BC government. Calling it "Pacific Time" is a political decision, and the timing of calling it "Pacific Time" is another political decision. TZDB should not override these decisions, because that injects TZDB further into politics, a problem that is bad enough as it is. We're just a small volunteer technical group, and we have neither the inclination nor the resources to fight political battles like this. From my point of view TZDB has gone out on a limb temporarily to help CLDR overcome CLDR's technical limitations. But I can't defend injecting TZDB into a Canada-vs-US political dispute indefinitely. CLDR should fix its technical limitations, and it should do that long before November rolls around.
CLDR doesn't have pre-1970 data, so I don't think this is currently a problem.
That sounds a bit short-sighted. The main reason TZDB introduced pre-1970 data in the first place, was to give insight as to what future problems may arise. That's why I gave that particular pre-1970 example. It's quite plausible with the daylight-saving changes bubbling under the surface in North America and the EU that CLDR will see problems like that to arise in the future, and CLDR shouldn't ignore the example merely because it occurred before 1970.
On Tue, 10 Mar 2026 at 13:17, Paul Eggert <eggert@cs.ucla.edu> wrote:
I would have told them to make the decree say that the law takes effect on 2026-11-01 – it would have been the same to them, but it seems like that would have forced your hand the other way.
Yes, of course if BC had done it the way CLDR wants, TZDB would have done it that way. That's our job.
And this is why there's a difference between a press release that effectively says "eight months to prepare for the law's impacts" and an order that effectively says "this law comes into force in seven days".
But I disagree that it would have been the same to the BC government. Calling it "Pacific Time" is a political decision, and the timing of calling it "Pacific Time" is another political decision.
Keep in mind also that the legislation was enacted in 2019 with the full expectation that western US states would follow suit and that it would not be brought into force without such coordination. The "Pacific Time" name was baked in then and could not simply be changed to something else by the BC Council when it decided to bring the law into force. So I would caution folks against reading into the apparent political nature of what may look like "Canadian Pacific Time" vs "US Pacific Time", and keep that very much separate from any of the myriad political reasons (internal or external) there may have been for the actual substance of the change as far as timekeeping goes, which TZDB merely describes as-needed and takes no position on. There is every chance that, as the very sorts of growing pains we've been discussing become more readily apparent to more people, the official name could soon be changed to something less confusing for all. -- Tim Parenti
On 2026-03-10 12:26, Tim Parenti via tz wrote:
On Tue, 10 Mar 2026 at 13:17, Paul Eggert <eggert@cs.ucla.edu <mailto:eggert@cs.ucla.edu>> wrote:
> I would have told them to make the > decree say that the law takes effect on 2026-11-01 – it would have been the > same to them, but it seems like that would have forced your hand the other > way.
Yes, of course if BC had done it the way CLDR wants, TZDB would have done it that way. That's our job.
And this is why there's a difference between a press release that effectively says "eight months to prepare for the law's impacts" and an order that effectively says "this law comes into force in seven days".
But I disagree that it would have been the same to the BC government. Calling it "Pacific Time" is a political decision, and the timing of calling it "Pacific Time" is another political decision.
Keep in mind also that the legislation was enacted in 2019 with the full expectation that western US states would follow suit and that it would not be brought into force without such coordination. The "Pacific Time" name was baked in then and could not simply be changed to something else by the BC Council when it decided to bring the law into force.
So I would caution folks against reading into the apparent political nature of what may look like "Canadian Pacific Time" vs "US Pacific Time", and keep that very much separate from any of the myriad political reasons (internal or external) there may have been for the actual substance of the change as far as timekeeping goes, which TZDB merely describes as-needed and takes no position on. There is every chance that, as the very sorts of growing pains we've been discussing become more readily apparent to more people, the official name could soon be changed to something less confusing for all.
It seems obvious that it would be called BC Time in Canada a la Yukon Time, or in Alberta, Yukon Time, just to annoy the left coast fruits and nuts ;^> -- 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 à retrancher but when there is no more to cut -- Antoine de Saint-Exupéry
So, assuming there's a genuine dispute between the US and Canada, where "Pacific Time" means one thing north of the border and a different thing south of the border, then I suppose in a Canadian locale CLDR will use the names "Pacific Time" and "US Pacific Time" respectively, whereas in a US locale CLDR will use "Canadian Pacific Time" and "Pacific Time" respectively.
Yes, with currencies we do exactly what you say: for CAD use $ in en-CA and CA$ in en; for USD use $ in en and US$ in CA (or something similar, the exact symbols vary by locale). We do have the ability (for example) on 2026-12-25 to have en_CA to display "11:00 Pacific Time", and en (= en-US) display "10:00 Pacific Time" for exactly the same time. There are many applications / websites that are not good about using the right locale id — the ones that display currencies have it hammered into them to get the right locale, but many others will probably fail. We're also considering always adding some disambiguating text, like "Pacific Time (Vancouver)" or "Pacific Time (Canada)".
From my point of view TZDB has gone out on a limb temporarily to help CLDR overcome CLDR's technical limitations.
Just a minor correction; it isn't really a technical limitation of CLDR per se, but rather that many implementations are not set up to update quickly. Fortunately most major implementations have learned the hard way to build in mechanisms to handle regular updates to the TZDB (with exceptions such as the Dublin change; but the TZDB adopted a mechanism to keep them working). And when the TZDB, say, adds a new timezone, the default behavior for implementations using CLDR is just to display the UTC offset (in a localized form) until they upgrade. Not pretty, but at least unambiguous. On Tue, Mar 10, 2026 at 10:16 AM Paul Eggert <eggert@cs.ucla.edu> wrote:
On 2026-03-09 14:37, Robert Bastian wrote:
If for some reason "Pacific Time" means one thing in the US and another in Canada, then that may cause problems for users but if those are the names the populace uses then the CLDR architecture should not (and as far as I know does not) insist on a unique string for each such name.
CLDR's names are unique within each format and locale
So, assuming there's a genuine dispute between the US and Canada, where "Pacific Time" means one thing north of the border and a different thing south of the border, then I suppose in a Canadian locale CLDR will use the names "Pacific Time" and "US Pacific Time" respectively, whereas in a US locale CLDR will use "Canadian Pacific Time" and "Pacific Time" respectively.
Another possibility will be to use the US-centric solution CLDR already uses for Australia, i.e., to use "Canadian Pacific Time" and "Pacific Time" regardless of which English-language locale you're using.
Either approach would work technically. Which approach are you leaning towards?
More generally, is there a publicly visible discussion thread or bug report about this on the CLDR side that non-CLDRers can follow? <https://cldr.unicode.org/index/downloads> points to <https://unicode-org.atlassian.net/issues/?filter=10837> and to <https://unicode-org.atlassian.net/issues/?filter=10838> but these seem to list only closed issues, whereas I assume this is an open issue.
I don't think following the law to the letter should be the ultimate priority, as laws are not written with these technical implications in mind. If the BC government had asked me
Yeah, they typically don't ask. The BC Attorney General's office didn't even respond to my repeated emails. I expect that their view is that they decide and we implement. And to a great extent they're right.
I would have told them to make the decree say that the law takes effect on 2026-11-01 – it would have been the same to them, but it seems like that would have forced your hand the other way.
Yes, of course if BC had done it the way CLDR wants, TZDB would have done it that way. That's our job.
But I disagree that it would have been the same to the BC government. Calling it "Pacific Time" is a political decision, and the timing of calling it "Pacific Time" is another political decision. TZDB should not override these decisions, because that injects TZDB further into politics, a problem that is bad enough as it is. We're just a small volunteer technical group, and we have neither the inclination nor the resources to fight political battles like this.
From my point of view TZDB has gone out on a limb temporarily to help CLDR overcome CLDR's technical limitations. But I can't defend injecting TZDB into a Canada-vs-US political dispute indefinitely. CLDR should fix its technical limitations, and it should do that long before November rolls around.
CLDR doesn't have pre-1970 data, so I don't think this is currently a problem.
That sounds a bit short-sighted. The main reason TZDB introduced pre-1970 data in the first place, was to give insight as to what future problems may arise. That's why I gave that particular pre-1970 example. It's quite plausible with the daylight-saving changes bubbling under the surface in North America and the EU that CLDR will see problems like that to arise in the future, and CLDR shouldn't ignore the example merely because it occurred before 1970.
Paul E. wrote:
... it's not really our job to disambiguate the names. If for some reason "Pacific Time" means one thing in the US and another in Canada, then that may cause problems for users but if those are the names the populace uses then the CLDR architecture should not (and as far as I know does not) insist on a unique string for each such name.
Paul, I believe that the populace will ultimately use whatever time zone names Microsoft, TZ-DB, and CLDR decide to publish. If Microsoft, TZ-DB, and/or CLDR choose to publish conflicting or ambiguous names for the sake of trying to follow the letter of the law, then collectively we will not have served the populace well. -chris On Mon, Mar 9, 2026 at 4:12 PM Paul Eggert via tz <tz@iana.org> wrote:
On 2026-03-09 07:34, Robert Bastian wrote:
America/Los_Angeles will use "Pacific Daylight Time" for UTC-7 this summer, so if Vancouver uses "Pacific Standard Time", to a user that is a strong indication that those are different offsets
But time zone names and abbreviations have never been unambiguous. As Robert alluded to, for years TZDB had "EST" (for "Eastern Standard Time") mean quite different things in Australia and in the US, and though confusing that's what popular usage was.
Although we may well may enter an era where time zone names are confusing for a different reason than North America vs Australia, it's not really our job to disambiguate the names. If for some reason "Pacific Time" means one thing in the US and another in Canada, then that may cause problems for users but if those are the names the populace uses then the CLDR architecture should not (and as far as I know does not) insist on a unique string for each such name.
I think the reason why CLDR hasn't associated "metazones" with offsets was to reduce the amount of churn and required releases.
Yes as I'm sure you know, the more CLDR gets into the business of deciding which time zone abbreviations and names should apply, the more churn and releases it will need, because events on the ground can move faster than CLDR's release cycle. Conversely, if CLDR keeps to its longstanding release cycles it will sometimes need to accept minor discrepancies (like "Pacific Standard Time" vs its preferred "Pacific Time") until the next CLDR release.
Maybe the takeaway here should be that changes to tm_isdst are as disruptive to CLDR as changes to offsets, so ideally should be done with some lead time.
For years the TZDB documentation has advised that the tm_isdst flag is almost never needed and its use should be discouraged, with the only plausible-albeit-imperfect exception (mktime) not applying to CLDR's use of the flag. Although understandably this sort of advice can take some time to follow, I hope this thread helps to underscore why the advice was given and why it's significant.
I'm not thrilled by the plan to retroactively revert the flag again
Nor am I. But it would be a mistake for TZDB to leave the flag wrong indefinitely merely because we want to be consistent with TZDB's earlier misrepresentation of the law. TZDB regularly fixes errors in past timestamps, and it will be able to do that even in this unusual case where the temporary error is intentional to accommodate CLDR's temporary limitations.
More generally, I hope CLDR follows TZDB's lead in preferring today's names for old timestamps, not yesterday's names. For example, the shell command "TZ=Europe/Berlin date -d '1918-11-11 12:00'" outputs the abbreviation "CET" (for "Central European Time", the current English-language name), not "MEZ" (for "Middle European Zone", the most common English-language name back in 1918). The idea is that TZDB (and I hope CLDR) does not attempt to determine or standardize terminology changes throughout history.
On 2026-03-09 15:32, Chris Walton via tz wrote:
I believe that the populace will ultimately use whatever time zone names Microsoft, TZ-DB, and CLDR decide to publish. This ascribes more power to Microsoft et al than they have, or at least should have. TZDB, at least, tries to follow a different approach, which describes rather than specifies how people and their clocks behave.
If Microsoft, TZ-DB, and/or CLDR choose to publish conflicting or ambiguous names for the sake of trying to follow the letter of the law
TZDB's goal is to describe what people do, and legislation is often a good way to figure that out. It is obviously not the only way. However, when there is disagreement it's often a reasonable tiebreaker.
On 2026-03-09 16:45, Paul Eggert via tz wrote:
On 2026-03-09 15:32, Chris Walton via tz wrote:
I believe that the populace will ultimately use whatever time zone names Microsoft, TZ-DB, and CLDR decide to publish. This ascribes more power to Microsoft et al than they have, or at least should have. TZDB, at least, tries to follow a different approach, which describes rather than specifies how people and their clocks behave.
If Microsoft, TZ-DB, and/or CLDR choose to publish conflicting or ambiguous names for the sake of trying to follow the letter of the law
TZDB's goal is to describe what people do, and legislation is often a good way to figure that out. It is obviously not the only way. However, when there is disagreement it's often a reasonable tiebreaker.
For that reason, given we have no idea what the bulk of folks will decide to use in Eastern and elsewhere in Canada, deferring to common and US practices, it would probably be best if the time zone were ascribed to the relevant authority as BC Time, like Yukon Time: don't blame the rest of us for their decisions ;^> -- 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 à retrancher but when there is no more to cut -- Antoine de Saint-Exupéry
Tim Parenti via tz wrote in <CAFpi07xpBQDhMkKvwRqgFwQWuQpds5KiDXtKYgJNggqMfLU6cg@mail.gmail.com>: ... |On Fri, 6 Mar 2026 at 18:27, Mark Davis Ⓤ via tz <tz@iana.org> wrote: | |> CLDR (and the software that uses it) does not use the TZDB abbreviations |> at all; it only depends on the timezone ID, and the offsets & tm_isdst |> flags produced by the TZDB rules. |> | |On Fri, 6 Mar 2026 at 17:01, Robert Bastian via tz <tz@iana.org> wrote: | |> All that ICU sees is tm_isdst=0. The link between time zones and their |> "metazone", which determine display names, comes from CLDR. | |A potential constructive suggestion here would be improving programmatic |checks in software using CLDR in conjunction with tzdata, such as ICU. In |particular, it seems wise to shift away from relying solely on the tm_isdst |flag (which per RFC 9636 is subject to the specifics of "law or practice"), |and to instead include calculated offsets in consideration. A bit hairy to note that just in the 2024 release of the POSIX standard there was Austin Group Defect 1614 is applied, clarifying the requirements for the tm_isdst member of the tm structure. and they made a painstaking effort (including the wonderful kre@ if i recall correctly) to come to The DESCRIPTION section says that mktime( ) converts the specified broken-down time into a time since the Epoch value. The use of the indefinite article here is necessary because, when tm_isdst is negative and the timezone has Daylight Saving Time transitions, there is not a one-to-one correspondence between broken-down times and time since the Epoch values. The description of how the value of tm_isdst affects the behavior of mktime( ) is shaded CX because the requirements in the ISO C standard are unclear. The next revision of the ISO C standard is expected to state the requirements using wording equivalent to the wording in this standard. There is more regarding issue 1614 and tm_isdst there. ... --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)
participants (12)
-
Annemarie Apple -
Brian Inglis -
Chris Walton -
Dag-Erling Smørgrav -
Doug Ewell -
Guy Harris -
Mark Davis Ⓤ -
Paul Eggert -
Robert Bastian -
Robert Elz -
Steffen Nurpmeso -
Tim Parenti