June 9, 2019
7:38 p.m.
I wrote:
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.
Whoops, wait. The pre-1970 "IST" is "Irish Summer Time", isn't it? Never mind. (Perils of relying on those pesky, ambiguous tz abbreviations.)