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/edc66fb4354f8ee6debbcf94faeb5496b38a5982/common/supplemental/metaZones.xml#L1462>.
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.
