> > CLDR provides textual names for time-zones, as an array [winter,
> > summer]. As a much larger project with considerable history the order
> > of that array is not going to change. (I'm using winter and summer for
> > CLDR for this email to aid clarity, they refer to them as standard and
> > daylight).
> >
> > TZDB provides the offsets, SAVE values and a short text string. This
> > text string - GMT/IST or IST/GMT - is not directly linkable to the
> > data CLDR provides. Although it may seem that you can use the text
> > from TZDB as a key to lookup the correct value in CLDR, I know from
> > painful experience that approach fails (as the TZDB text varies over
> > time, has the same text in winter and summer, or isn't even text).
> > Thus, the only reliable way to pick which piece of CLDR data is needed
> > is from the offsets.
> >
> > For 20 years, this has been done in a simple and straightforward way -
> > if (raw-offset != actual-offset) then CLDR uses summer text and array
> > element 1. This provides the necessary glue to link the two projects:
> >
> > boolean inSummerTime(instant) {
> >  return getRawOffset(instant) != getActualOffset(instant)
> > }
> > zoneName = inSummerTime(instant) ? cldr-summer-time-text : cldr-
> winter-time-text
>
> OK, so "instant" isn't passed to localtime() or localtime_r(), or to
> code in CLDR that does the same thing that those functions do, to
> get tm_isdst or the equivalent information?
>
> How does CLDR determine those offsets?

CLDR does not determine offsets. CLDR just maintains an array of names
by category. In CLDR, we define several different type of names for
a zone (and localized names in various locales) -

1. Long standard (e.g. Pacific Standard Time)
2. Long daylight (e.g. Pacific Daylight Time)
3. Long generic (e.g. Pacific Time)
4. Short standard (e.g. PST)
5. Short daylight (e.g. PDT)
6. Short generic (e.g. PT)

And the set of name may change time to time for a single location.
The problem is that CLDR currently uses "Irish Standard Time" for 2. Long
daylight, and "Greenwich Mean Time" for 1. Long standard.

CLDR consumers, such as Java, ICU, node, etc.. rely on the labeling,
but handling actual UTC offset separately.

If CLDR strictly follows the 2018a Dublin rules, then a consumer code
without the change suddenly flips summer/winter names.

As Stephen Colebourne mentioned, this is the most difficult part for
library/platform maintainer. CLDR downstream consumers usually maintain
code (calculating clocks) and localized time zone name data separately
from different sources. Usually, localized time zone name data is assumed as
more stable data, and consumers of CLDR assumes it does not require frequent
updates. So they usually don't have mechanism for updating name data only.


-Yoshito