> OK, but I'm a bit puzzled about the details here. Robert wrote that CLDR
> was planning to ship a patched copy of TZDB in ICU. If so, what's the
> problem with changing TZDB along the lines already suggested? Even with
> such a change, CLDR users will see patched TZDB data, and then CLDR can
> decide on its own schedule how to resolve the "Pacific Time" mess, and
> once it does that it can go back to shipping an unmodified copy of TZDB.

This will fix the issue for Android and Chrome, which use ICU's internal TZDB instead of the system's for formatting. I have no idea if this fix would work for other systems.

> They are not immediate for many of the systems I use. It can take many
> months, particularly with devices that are not networked or that are
> maintained only fitfully by their suppliers.

While there are certainly devices where the updates take months, the primary devices that billions of users interact with every day (Android, iOS, macOS, mainstream Linux distributions) update in a matter of days.

> I don't see a major breakage here. If I understand things correctly,
> America/Vancouver people combining older CLDR with newer TZDB would see
> "Pacific Standard Time" instead of the legally-specified "Pacific Time".
> Although infelicitous to experts, that string isn't "broken": it's close
> enough to the real thing for most users, and only time pedants and maybe
> politicians will care.

It could be argued that Pacific Standard Time is correct now. However, there are certainly users who are aware of the difference between Pacific Daylight Time and Pacific Standard Time. The broader issue is also that 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 (in all other cases, "standard" != "daylight"). This matters in scenarios where both time zones are present, such as with time zone pickers, TV schedules, meetings, travel between the time zones, etc.

> A potential constructive suggestion here would be improving programmatic checks in software using CLDR in conjunction with tzdata, such as ICU.  In particular, it seems wise to shift away from relying solely on the tm_isdst flag (which per RFC 9636 is subject to the specifics of "law or practice"), and to instead include calculated offsets in consideration.

I think the reason why CLDR hasn't associated "metazones" with offsets was to reduce the amount of churn and required releases. The same name can be used for different offsets at different times: "Yakutsk Time" meant UTC+10 before 2014 and UTC+9 since then, but the 2014 TZDB update didn't require a CLDR update, because that string just changed meaning (well, it always meant "the time in Yakutsk"). Similarly, if the US west coast had announced permanent UTC-7 last week as well, we wouldn't have to change anything in CLDR, all those zones could keep using "Pacific Time", which would now just mean something else. So there is a balance to be kept wrt the amount of information that we track in CLDR (we certainly don't want to maintain our own time zone database).

We have, in fact, added explicit metazone offsets to the CLDR data model in the last version, but so far only used them for some zones where the tm_isdst value from TZDB doesn't agree with our model of what a daylight saving time is (Europe/Dublin, Africa/Windhoek). The long term goal is to not require rearguard data anymore, but the cost of course is that we have to maintain these offsets. However, using this data has currently only been implemented in the new ICU4X library, where we're not restricted by ICU's data backward compatibility.

> The workaround should accommodate CLDR's current
> limitation, by marking these timestamps with tm_isdst as requested. The
> plan is to remove the temporary workaround once CLDR is updated to
> remove the limitation, which as I understand it can be done by a CLDR
> release before November.

I'm not thrilled by the plan to retroactively revert the flag again, because then we either have to keep patching the TZDB for this summer anyway, or users will get different display names depending on their TZDB version. But this fixes the immediate issue for us and we can work on solutions in ICU.

> This episode is a bit of a wakeup call for the coordination between TZDB
> and CLDR. Although in the past we've lucked out with similar changes in
> Yukon and elsewhere

This does not seem to be the first TZDB/CLDR issue of this nature. In 2018 the change to Dublin's tm_isdst would have broken ICU (and other consumers afaict) as it would have flipped the summer/winter display names. The solution back then was to create the rearguard format, which ICU/CLDR require to this day, and which some major platforms ship, potentially in part because of ICU. 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.

On Sun, 8 Mar 2026 at 23:46, Mark Davis Ⓤ <mark@unicode.org> wrote:
Good points. 

We had already been considering doing away with depending upon the flag, and you have some other useful suggestions.

Our fallback is to drop back to different time zone formats, but it was not as automatic as it should be.

On Sun, Mar 8, 2026, 12:05 Tim Parenti <tim@timtimeonline.com> wrote:

On Sat, 7 Mar 2026 at 17:00, Paul Eggert via tz <tz@iana.org> wrote:
This episode is a bit of a wakeup call for the coordination between TZDB
and CLDR. Although in the past we've lucked out with similar changes in
Yukon and elsewhere, we will likely not be so lucky in plausible future
changes to timekeeping in North America, the EU, and other places where
people are considering abolishing DST transitions and changing time
zones and time zone names.

I agree.  I understand since there is a lot of translation work involved, the roughly-twice-a-year release cadence for CLDR and ICU is not likely to change.  It seems to me, then, that both projects ought to aim toward being more resilient to sudden, unexpected changes in TZDB data, especially given those release dates' apparent proximity to the typical "silly seasons" within the timekeeping world.

We can certainly do our part, as well, in helping to smooth over some rough edges as we have here, but we will not be able to predict everything that might possibly be thrown at us.  Our remit remains ensuring wall-clock times can be accurately computed — even in the face of changes where there may no longer be a good display name for it, or a former display name may become otherwise unsuitable.  Downstream projects should expect that any assumptions related to actual timekeeping practices are subject to sudden breakage.


On Fri, 6 Mar 2026 at 18:27, Mark Davis Ⓤ via tz <tz@iana.org> wrote:
CLDR (and the software that uses it) does not use the TZDB abbreviations at all; it only depends on the timezone ID, and the offsets & tm_isdst flags produced by the TZDB rules.

On Fri, 6 Mar 2026 at 17:01, Robert Bastian via tz <tz@iana.org> wrote:
All that ICU sees is tm_isdst=0. The link between time zones and their "metazone", which determine display names, comes from CLDR.

A potential constructive suggestion here would be improving programmatic checks in software using CLDR in conjunction with tzdata, such as ICU.  In particular, it seems wise to shift away from relying solely on the tm_isdst flag (which per RFC 9636 is subject to the specifics of "law or practice"), and to instead include calculated offsets in consideration.


For example, if software such as ICU detects that tzdata has calculated an offset which CLDR does not expect for the zone ID in question (that is, one not specified by the currently active "metazone" in CLDR), then the selected "format"/display name could fallback to a reasonable default like "UTC±N" in the absence of anything better.  Ex: Updated tzdata calculates −7 into the indefinite future for America/Vancouver; CLDR already calls this "Pacific Daylight Time" for that zone and so software continues to display that unless/until a more suitable name emerges and a CLDR update is installed to reflect it.  (But if tzdata later calculated −9 for some reason, it would fail to "UTC−9".)

For greater specificity, one could perhaps trigger this default on unexpected (offset, tm_isdst) tuples instead of just offset.  Ex: CLDR expects to refer to (−8, 0) as "Pacific Standard Time" and (−7, 1) as "Pacific Daylight Time", but does not yet have a name for (−7, 0) and so software would fail gracefully to "UTC−7" until CLDR can be patched.  This could act as a signal to both end-users and developers that something has changed (whether an outright offset or the "law or practice" indicated by the flag) and that extra caution should be exercised in the meantime.

Whether "anything better" than "UTC±N" already exists could maybe be determined, in part, by looking at any inactive/past "metazones" for the zone ID in question, to see whether there is a history of using an older "format"/display name in that region which could suffice until CLDR can more thoroughly review.  Those heuristics may get a bit thorny, though, especially as one looks further back — so simpler signals based on calculated offsets likely balance concerns better.

--
Tim Parenti