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