Paul Eggert wrote:
Steve Summit wrote:
I'm not sure that's an entirely fair challenge, though. Given that (as I understand it) Java and ICU/CLDR use tt_isdst to decide whether to display their equivalents of "GMT" or "IST", I don't think they *can* get the right answer near 1970
Yes, Ireland in 1970 is an "unfair" challenge. That was its point. It was intended to illustrate the inadequacy of the current CLDR/Java model to represent real-world aspects of civil timekeeping.
tzdb changed its mind about the mapping at that point.
I'm not sure what you mean by "mapping",
Java/CLDR's mapping wants to be dst=0 -> GMT, dst=1 -> IST, which is of course incompatible with tzdb's current mapping. But if Java/CLDR were to somehow change to dst=0 -> IST, dst=1 -> GMT, to match tzdb's current mapping, it would then start getting the wrong answer before 1970, because for dates before 1970 (in 2019a, at least), tzdb uses dst=0 -> GMT, dst=1 -> IST.