[tz] [english 100%] Re: [english 100%] Re: [english 100%] Re:OpenJDK/CLDR/ICU/Joda issues with Irelandchange
mhochschild at gmx.de
Fri Jan 26 22:15:48 UTC 2018
@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
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.
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
>>>> 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
>>>> "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
> 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
> 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:
> which should avoid the need for an extra column or an extra file.
More information about the tz