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