<tt><font size=2>> > CLDR provides textual names for time-zones,
as an array [winter,<br>> > summer]. As a much larger project with considerable history the
order<br>> > of that array is not going to change. (I'm using winter and summer
for<br>> > CLDR for this email to aid clarity, they refer to them as standard
and<br>> > daylight).<br>> > <br>> > TZDB provides the offsets, SAVE values and a short text string.
This<br>> > text string - GMT/IST or IST/GMT - is not directly linkable to
the<br>> > data CLDR provides. Although it may seem that you can use the
text<br>> > from TZDB as a key to lookup the correct value in CLDR, I know
from<br>> > painful experience that approach fails (as the TZDB text varies
over<br>> > time, has the same text in winter and summer, or isn't even text).<br>> > Thus, the only reliable way to pick which piece of CLDR data
is needed<br>> > is from the offsets.<br>> > <br>> > For 20 years, this has been done in a simple and straightforward
way -<br>> > if (raw-offset != actual-offset) then CLDR uses summer text and
array<br>> > element 1. This provides the necessary glue to link the two projects:<br>> > <br>> > boolean inSummerTime(instant) {<br>> >  return getRawOffset(instant) != getActualOffset(instant)<br>> > }<br>> > zoneName = inSummerTime(instant) ? cldr-summer-time-text : cldr-<br>> winter-time-text<br>> <br>> OK, so "instant" isn't passed to localtime() or localtime_r(),
or to<br>> code in CLDR that does the same thing that those functions do, to
<br>> get tm_isdst or the equivalent information?<br>> <br>> How does CLDR determine those offsets?<br></font></tt><br><tt><font size=2>CLDR does not determine offsets. CLDR just maintains
an array of names</font></tt><br><tt><font size=2>by category. In CLDR, we define several different
type of names for</font></tt><br><tt><font size=2>a zone (and localized names in various locales) -</font></tt><br><br><tt><font size=2>1. Long standard (e.g. Pacific Standard Time)</font></tt><br><tt><font size=2>2. Long daylight (e.g. Pacific Daylight Time)</font></tt><br><tt><font size=2>3. Long generic (e.g. Pacific Time)</font></tt><br><tt><font size=2>4. Short standard (e.g. PST)</font></tt><br><tt><font size=2>5. Short daylight (e.g. PDT)</font></tt><br><tt><font size=2>6. Short generic (e.g. PT)</font></tt><br><br><tt><font size=2>And the set of name may change time to time for a
single location.</font></tt><br><tt><font size=2>The problem is that CLDR currently uses "Irish
Standard Time" for 2. Long</font></tt><br><tt><font size=2>daylight, and "Greenwich Mean Time" for
1. Long standard.</font></tt><br><br><tt><font size=2>CLDR consumers, such as Java, ICU, node, etc.. rely
on the labeling,</font></tt><br><tt><font size=2>but handling actual UTC offset separately.</font></tt><br><br><tt><font size=2>If CLDR strictly follows the 2018a Dublin rules, then
a consumer code</font></tt><br><tt><font size=2>without the change suddenly flips summer/winter names.</font></tt><br><br><tt><font size=2>As Stephen Colebourne mentioned, this is the most
difficult part for</font></tt><br><tt><font size=2>library/platform maintainer. CLDR downstream consumers
usually maintain</font></tt><br><tt><font size=2>code (calculating clocks) and localized time zone
name data separately</font></tt><br><tt><font size=2>from different sources. Usually, localized time zone
name data is assumed as</font></tt><br><tt><font size=2>more stable data, and consumers of CLDR assumes it
does not require frequent</font></tt><br><tt><font size=2>updates. So they usually don't have mechanism for
updating name data only.</font></tt><br><br><br><tt><font size=2>-Yoshito</font></tt><br><br><br><BR>