About the wish for the restriction that a set of rule lines with same name should not have mixed signs of dst offsets, I will try to explain. The whole thing is about labelling what the zero dst offset stands for. If such a set of rule lines only contains either positive or zero SAVE then the zero dst offset corresponds to winter time (default). If the set of rules only contains negative or zero SAVE then the zero dst offset corresponds to summer time (Eire). But if we have both negative and positive and zero offsets then how to label the zero dst offset? A human being might guess it by looking at the year context, but I am not sure if a machine tool can do it, too. Would be a hard nut to crack. By the way, I don't mind if my suggestion of introducing an optional META column at the end of a rule line might be modified such that we get a new file with similar content (with the advantage not to change the zic input format). And even then I would prefer not to have mixed signs within the same set of rules equally named. It makes programming much easier. And I also believe that such a new file is not increasing the maintenance burden so much because a case like Ireland is rather rare (okay and maybe also Egypt or Morocco with ramadan time or historic double dst offset in some countries shortly after second world war). With best regards Meno Am 26.01.2018 um 23:25 schrieb Paul Eggert:
On 01/26/2018 02:15 PM, Meno Hochschild wrote:
Let's imagine that Ireland will one day start to consider the winter time as standard and rename both winter and summer time accordingly. Would the tzdb maintainers then "reuse" the "Eire"-rules for the new positive dst offset? I hope not and ask if a new ruleset with a different new name can be taken into consideration. Can I rely on that?
I'm afraid not, as that restriction is not in the code or the documentation. Also, I don't see why the restriction would help; it seems a bit arbitrary.
By the way: I discovered that the current practice in Java is broken for Ireland in the years 1968-71 where OpenJDK just prints "Greenwich Mean Time" althoug it should be read as "Irish Standard Time". My adjusted tz-compiler has finally coped with the right naming using the version v2018b but would be broken again with new version v2018c (and Java remains broken here for the years 1968-71 in Ireland). So the reverted change in v2018c is not really an improvement (and for me even worse).
Yes, sorry about that. I'm hoping to come up with a scheme that will support both old-style (2017c and earlier) and new-style (2018a and 2018b) approaches soon. As usual I'll publish proposed patches before distributing a new release, and I hope you'll try them out.
The new version v2018c is only good for OpenJDK when handling Ireland now in year 2018.
Yes, this is a known issue with CLDR, discussed here:
https://mm.icann.org/pipermail/tz/2018-January/025974.html
which says that CLDR doesn't worry about timestamps before 1990.