On Mon, 2 Nov 2020 18:14:47 GMT, Naoto Sato <na...@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
