> 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, and ICU has datetime parsing that round trips. Short names are only used where they are commonly understood, e.g. "HNR" is only used in Canadian French, European French uses "UTC-7" in the short format (but "heure normale des Rocheuses" in the long format). > But it would be a mistake for TZDB to leave the flag wrong > indefinitely merely because we want to be consistent with TZDB's earlier > misrepresentation of the law. 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, 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. > More generally, I hope CLDR follows TZDB's lead in preferring today's > names for old timestamps, not yesterday's names. For example, the shell > command "TZ=Europe/Berlin date -d '1918-11-11 12:00'" outputs the > abbreviation "CET" (for "Central European Time", the current > English-language name), not "MEZ" (for "Middle European Zone", the most > common English-language name back in 1918). The idea is that TZDB (and I > hope CLDR) does not attempt to determine or standardize terminology > changes throughout history. CLDR doesn't have pre-1970 data, so I don't think this is currently a problem. On Mon, 9 Mar 2026 at 21:11, Paul Eggert <[email protected]> wrote: > On 2026-03-09 07:34, Robert Bastian wrote: > > America/Los_Angeles will use "Pacific Daylight Time" for UTC-7 this > summer, > > so if Vancouver uses "Pacific Standard Time", to a user that is a strong > > indication that those are different offsets > > But time zone names and abbreviations have never been unambiguous. As > Robert alluded to, for years TZDB had "EST" (for "Eastern Standard > Time") mean quite different things in Australia and in the US, and > though confusing that's what popular usage was. > > Although we may well may enter an era where time zone names are > confusing for a different reason than North America vs Australia, it's > not really our job to disambiguate the names. 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. > > > > I think the reason why CLDR hasn't associated "metazones" with offsets > was > > to reduce the amount of churn and required releases. > > Yes as I'm sure you know, the more CLDR gets into the business of > deciding which time zone abbreviations and names should apply, the more > churn and releases it will need, because events on the ground can move > faster than CLDR's release cycle. Conversely, if CLDR keeps to its > longstanding release cycles it will sometimes need to accept minor > discrepancies (like "Pacific Standard Time" vs its preferred "Pacific > Time") until the next CLDR release. > > > > Maybe the takeaway here should be that changes to > > tm_isdst are as disruptive to CLDR as changes to offsets, so ideally > should > > be done with some lead time. > > For years the TZDB documentation has advised that the tm_isdst flag is > almost never needed and its use should be discouraged, with the only > plausible-albeit-imperfect exception (mktime) not applying to CLDR's use > of the flag. Although understandably this sort of advice can take some > time to follow, I hope this thread helps to underscore why the advice > was given and why it's significant. > > > > I'm not thrilled by the plan to retroactively revert the flag again > > Nor am I. But it would be a mistake for TZDB to leave the flag wrong > indefinitely merely because we want to be consistent with TZDB's earlier > misrepresentation of the law. TZDB regularly fixes errors in past > timestamps, and it will be able to do that even in this unusual case > where the temporary error is intentional to accommodate CLDR's temporary > limitations. > > More generally, I hope CLDR follows TZDB's lead in preferring today's > names for old timestamps, not yesterday's names. For example, the shell > command "TZ=Europe/Berlin date -d '1918-11-11 12:00'" outputs the > abbreviation "CET" (for "Central European Time", the current > English-language name), not "MEZ" (for "Middle European Zone", the most > common English-language name back in 1918). The idea is that TZDB (and I > hope CLDR) does not attempt to determine or standardize terminology > changes throughout history. >
