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