Following up on Paul's explanation of why a correct tzdb entry can still fail
to show up downstream: I found it helpful to lay out the propagation chain
explicitly, using Coyhaique as the worked example. Perhaps it's useful for
future reports of the same kind.
tzdb release
| America/Coyhaique added in 2025b (2025-03-22)
v
CLDR
| added in CLDR 48 (2025-10-30)
v
ICU / V8 / other CLDR consumers
| bundle a specific CLDR version; e.g. Node 24's V8
| shipped CLDR 47, so no localization at first
v
Language runtimes / OS / libraries
| Node 24 "Krypton" (2025-10-28) lacked the localized
| name until 24.13.0 (2026-01-13)
v
End-user applications
and many deployments lag further behind their
runtime's latest release
Two points this makes visible:
- The raw zone and its localized name propagate separately. A system can
resolve America/Coyhaique as an offset while still having no display name for
it, because the offset comes from tzdb and the name comes from CLDR, on
different schedules.
- Each hop adds its own delay, so the effective lag a user sees is the sum of
the chain, not any single component. This is why a fix present in tzdb for
months may not reach a given app for much longer.
As Paul noted, none of this is actionable in tzdb itself. The value is mainly
in pinpointing which hop a given complaint is stuck at.
Corrections to the specifics above are welcome.
