[tz] [english 100%] Re: [english 100%] Re: [english 100%] Re:OpenJDK/CLDR/ICU/Joda issues with Irelandchange

[Meno Hochschild]

@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 at 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.
>