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

[Naoto Sato]

On Mon, 2 Nov 2020 18:06:28 GMT, Kiran Sidhartha Ravikumar <kravikumar at openjdk.org> wrote:

>> test/jdk/sun/util/calendar/zi/TestZoneInfo310.java line 201:
>> 
>>> 199:                 zid.equals("Iran") || // last rule mismatch
>>> 200:                 zid.equals("Asia/Gaza") || // last rule mismatch
>>> 201:                 zid.equals("Asia/Hebron")) { // last rule mismatch
>> 
>> Can you explain why these zones are failing? The criteria for excluding failing tests here is that the zone has negative dst and last rules beyond 2037, and I don't think those newly excluded zones suffice those.
>
> 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.

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

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