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