@Paul Eggert When I elaborated my workaround for v2018b (which works fine now) I have made at least the assumption that a rule set consisting of rule lines having the same name will not contain a mixture of both negative and positive dst offsets. Otherwise my approach will probably be broken. 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? 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). The new version v2018c is only good for OpenJDK when handling Ireland now in year 2018. Meno Am 26.01.2018 um 16:51 schrieb Paul Eggert:
Stephen Colebourne wrote:
On 26 January 2018 at 07:46, Paul Eggert <eggert@cs.ucla.edu> wrote:
Meno Hochschild wrote:
I have adjusted my tzdb-compiler (Time4J) such that it looks if all rule lines referencing the same name (here: Eire) contain any negative dst offsets. If yes then let's assume summer time for SAVE=0 and winter time for SAVE < 0. So I can still work with old unchanged CLDR-entries for getting "Irish Standard Time" in summer.
This sounds like a good idea regardless of whether we make changes to zic input. Couldn't OpenJDK do the same?
Such an approach is merely adding an even more subtle API to TZDB, one where a mixture of positive and negative SAVE values would cause chaos.
What sort of chaos, exactly? Meno Hochschild is not reporting any chaos.
Meno's approach with an extra column actually tackles the heart of the problem by providing a stable key that can be used to link the two projects.
Such a key could be given in a separate data file, which could be used by zi parsers that do not support negative DST offsets, or that have other specialized requirements. That would be less disruptive than changing zic input format for purposes unrelated to zic.
For this particular issue I'm hoping that we can use an even less-disruptive approach, such as the one proposed here:
https://mm.icann.org/pipermail/tz/2018-January/026002.html
which should avoid the need for an extra column or an extra file.