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.

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?

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

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

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

...

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

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

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

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.

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?

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?

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

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.

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.

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)