<div dir="ltr"><div><br></div>On 24 January 2018 at 11:19, Robert Elz <span dir="ltr"><<a href="mailto:kre@munnari.oz.au" target="_blank">kre@munnari.oz.au</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-">  | CLDR provides textual names for time-zones, as an array [winter,<br>  | summer].<br><br></span>That itself is a bug.   It assumes there are just two (not including for<br>the "generic" name, mentioned in a later message from Yoshito Umaoka, which<br>is probably the more useful one of the three anyway) - and there is<br>no guarantee that will (or even always has) remain true.<br><br>There is nothing to stop some locality (probably one at a high latitude)<br>from deciding that they should advance the clocks in early spring, and<br>then advance them further in early-mid summer, returning to the intermediate<br>(or some other) value in late summer, and then to the original in late<br>autumn (or fall if autumn happens to be called that in the relevant<br>location).  What's more, they could give 4 different names to the 3 (or 4)<br>different offsets, perhaps "winter time" "spring time" "summer time" and<br>"autumn time" with 4 different abbreviations.<br><br>There could even be a mid winter fallback of even more, just as there<br>could be a mid summer skip forward of more.</blockquote><div><br></div>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.<div><br></div><div><a href="https://github.com/eggert/tz/blob/975e499378112668e2e8b495badce684828aeec0/antarctica#L219">https://github.com/eggert/tz/blob/975e499378112668e2e8b495badce684828aeec0/antarctica#L219</a></div><div><br></div><div>Indeed, CLDR having an array that only allows for two descriptive names <i>is</i> 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.<br><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature">--<br>Tim Parenti</div></div></div></div></div>