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

[Meno Hochschild]

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