On 24 January 2018 at 11:19, Robert Elz <kre@munnari.oz.au> wrote:
| CLDR provides textual names for time-zones, as an array [winter,
| summer].
That itself is a bug. It assumes there are just two (not including for
the "generic" name, mentioned in a later message from Yoshito Umaoka, which
is probably the more useful one of the three anyway) - and there is
no guarantee that will (or even always has) remain true.
There is nothing to stop some locality (probably one at a high latitude)
from deciding that they should advance the clocks in early spring, and
then advance them further in early-mid summer, returning to the intermediate
(or some other) value in late summer, and then to the original in late
autumn (or fall if autumn happens to be called that in the relevant
location). What's more, they could give 4 different names to the 3 (or 4)
different offsets, perhaps "winter time" "spring time" "summer time" and
"autumn time" with 4 different abbreviations.
There could even be a mid winter fallback of even more, just as there
could be a mid summer skip forward of more.
In fact, this has apparently been the case for Antarctica/Troll for quite some time. Although the data is a little rough, and it is currently commented out to avoid compatibility issues, the clear intent is to eventually model it as correctly as possible — a warning that has been present in this project for nearly four years already.
Indeed, CLDR having an array that only allows for two descriptive names is a bug and an incompatibility with tz. If proper attention had been paid to the implicit dependencies of that project, this would be well-known already. While CLDR addresses this issue, some additional thought should go into how linkages with tz data are handled, as Robert Elz mentioned, so that if the translated/descriptive strings for a time zone need to depend on the version of the tz data that generated them, they can… at which point the problem of the projects independently patching will be about as solved as it can be.