<i18n dev> RFR: 8255226: (tz) Upgrade time-zone data to tzdata2020d

[Kiran Sidhartha Ravikumar]

On Mon, 2 Nov 2020 18:14:47 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> It's probably these last rule what is causing the issue
>> 
>> Rule Palestine	2020	max	-	Mar	Sat>=24	0:00	1:00	S
>> Rule Palestine	2020	max	-	Oct	Sat>=24	1:00	0	-
>> 
>> The failure seen is 
>> 
>> ******************************
>> Asia/Gaza : Asia/Gaza
>>     -------------
>>     SimpleTimeZone (NG)
>>        stz=java.util.SimpleTimeZone[id=Asia/Gaza,offset=7200000,dstSavings=3600000,useDaylight=true,startYear=0,startMode=2,startMonth=2,startDay=-1,startDayOfWeek=7,startTime=0,startTimeMode=0,endMode=2,endMonth=9,endDay=-1,endDayOfWeek=7,endTime=3600000,endTimeMode=0]
>>       stz0=java.util.SimpleTimeZone[id=Asia/Gaza,offset=7200000,dstSavings=3600000,useDaylight=true,startYear=0,startMode=3,startMonth=2,startDay=24,startDayOfWeek=7,startTime=0,startTimeMode=0,endMode=3,endMonth=9,endDay=24,endDayOfWeek=7,endTime=3600000,endTimeMode=0]
>
> My question is why it is failing. Have you figured it? The existing exceptions are either negative DST or last rule beyond 2037, which javazic cannot handle. The changes introduced with 2020d does not meet either of them. Unless we know why it is failing, we cannot be sure we can exclude it.

Thanks for getting back Naoto, I believe this is a long-standing issue - https://bugs.openjdk.java.net/browse/JDK-8227293.

Looking back at the integration of tzdata2019a/tzdata2019b, the same issue was addressed by updating the source code - https://hg.openjdk.java.net/jdk/jdk/rev/79036e5e744b#l13.1. 

Here is some history to the issue - https://mail.openjdk.java.net/pipermail/i18n-dev/2019-July/002887.html

Please let me know your thoughts

-------------

PR: https://git.openjdk.java.net/jdk/pull/1012