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.
