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.