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.