> 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 <[email protected]> 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. > >
