Re: RFR: 8255226: (tz) Upgrade time-zone data to tzdata2020d [v3]

2020-11-03 Thread Naoto Sato
On Tue, 3 Nov 2020 15:49:09 GMT, Kiran Sidhartha Ravikumar 
 wrote:

>> Hi Guys,
>> 
>> Please review the integration of tzdata2020d to JDK.
>> 
>> Details regarding the change can be viewed at - 
>> https://mm.icann.org/pipermail/tz-announce/2020-October/62.html
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8255226
>> 
>> TestZoneInfo310.java test failure is addressed along with it. The last rule 
>> affects "Asia/Gaza" and "Asia/Hebron" and therefore excluded from the test.
>> 
>> Regression Tests pass along with JCK.
>> 
>> Please let me know if the changes are good to push.
>> 
>> Thanks,
>> Kiran
>
> Kiran Sidhartha Ravikumar has updated the pull request incrementally with one 
> additional commit since the last revision:
> 
>   8255226: Fixing whitespaces

Looks good.

-

Marked as reviewed by naoto (Reviewer).

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


Re: RFR: 8255226: (tz) Upgrade time-zone data to tzdata2020d [v3]

2020-11-03 Thread Kiran Sidhartha Ravikumar
> Hi Guys,
> 
> Please review the integration of tzdata2020d to JDK.
> 
> Details regarding the change can be viewed at - 
> https://mm.icann.org/pipermail/tz-announce/2020-October/62.html
> Bug: https://bugs.openjdk.java.net/browse/JDK-8255226
> 
> TestZoneInfo310.java test failure is addressed along with it. The last rule 
> affects "Asia/Gaza" and "Asia/Hebron" and therefore excluded from the test.
> 
> Regression Tests pass along with JCK.
> 
> Please let me know if the changes are good to push.
> 
> Thanks,
> Kiran

Kiran Sidhartha Ravikumar has updated the pull request incrementally with one 
additional commit since the last revision:

  8255226: Fixing whitespaces

-

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1012/files
  - new: https://git.openjdk.java.net/jdk/pull/1012/files/8782181c..e4a565e2

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk=1012=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk=1012=01-02

  Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1012.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1012/head:pull/1012

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


Re: RFR: 8255226: (tz) Upgrade time-zone data to tzdata2020d [v2]

2020-11-03 Thread Kiran Sidhartha Ravikumar
On Tue, 3 Nov 2020 00:21:16 GMT, Naoto Sato  wrote:

>> 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
>
> Should we then remove the hack in the ZoneInfoFile.java that excludes 
> Gaza/Hebron instead?

I had made changes to the ZoneInfoFile.java to avoid applying the logic present 
to Gaza/Hebron. Regression tests executed successfully.

-

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


Re: RFR: 8255226: (tz) Upgrade time-zone data to tzdata2020d [v2]

2020-11-03 Thread Kiran Sidhartha Ravikumar
> Hi Guys,
> 
> Please review the integration of tzdata2020d to JDK.
> 
> Details regarding the change can be viewed at - 
> https://mm.icann.org/pipermail/tz-announce/2020-October/62.html
> Bug: https://bugs.openjdk.java.net/browse/JDK-8255226
> 
> TestZoneInfo310.java test failure is addressed along with it. The last rule 
> affects "Asia/Gaza" and "Asia/Hebron" and therefore excluded from the test.
> 
> Regression Tests pass along with JCK.
> 
> Please let me know if the changes are good to push.
> 
> Thanks,
> Kiran

Kiran Sidhartha Ravikumar has updated the pull request with a new target base 
due to a merge or a rebase. The incremental webrev excludes the unrelated 
changes brought in by the merge/rebase. The pull request contains three 
additional commits since the last revision:

 - Merge remote-tracking branch 'origin/master' into JDK-8255226
 - 8255226: Updating ZoneInfoFile.java logic to avoid certain zones
 - 8255226: (tz) Upgrade time-zone data to tzdata2020d

-

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1012/files
  - new: https://git.openjdk.java.net/jdk/pull/1012/files/e859af83..8782181c

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk=1012=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk=1012=00-01

  Stats: 2120 lines in 83 files changed: 1178 ins; 580 del; 362 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1012.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1012/head:pull/1012

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


Re: RFR: 8255226: (tz) Upgrade time-zone data to tzdata2020d

2020-11-02 Thread Naoto Sato
On Tue, 3 Nov 2020 00:00:26 GMT, Kiran Sidhartha Ravikumar 
 wrote:

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

Should we then remove the hack in the ZoneInfoFile.java that excludes 
Gaza/Hebron instead?

-

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


Re: RFR: 8255226: (tz) Upgrade time-zone data to tzdata2020d

2020-11-02 Thread Kiran Sidhartha Ravikumar
On Mon, 2 Nov 2020 18:14:47 GMT, Naoto Sato  wrote:

>> It's probably these last rule what is causing the issue
>> 
>> Rule Palestine   2020max -   Mar Sat>=24 0:001:00
>> S
>> Rule Palestine   2020max -   Oct Sat>=24 1:000   
>> -
>> 
>> The failure seen is 
>> 
>> **
>> Asia/Gaza : Asia/Gaza
>> -
>> SimpleTimeZone (NG)
>>
>> stz=java.util.SimpleTimeZone[id=Asia/Gaza,offset=720,dstSavings=360,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=360,endTimeMode=0]
>>   
>> stz0=java.util.SimpleTimeZone[id=Asia/Gaza,offset=720,dstSavings=360,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=360,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


Re: RFR: 8255226: (tz) Upgrade time-zone data to tzdata2020d

2020-11-02 Thread Naoto Sato
On Mon, 2 Nov 2020 18:06:28 GMT, Kiran Sidhartha Ravikumar 
 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 Palestine2020max -   Mar Sat>=24 0:001:00
> S
> Rule Palestine2020max -   Oct Sat>=24 1:000   
> -
> 
> The failure seen is 
> 
> **
> Asia/Gaza : Asia/Gaza
> -
> SimpleTimeZone (NG)
>
> stz=java.util.SimpleTimeZone[id=Asia/Gaza,offset=720,dstSavings=360,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=360,endTimeMode=0]
>   
> stz0=java.util.SimpleTimeZone[id=Asia/Gaza,offset=720,dstSavings=360,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=360,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


Re: RFR: 8255226: (tz) Upgrade time-zone data to tzdata2020d

2020-11-02 Thread Kiran Sidhartha Ravikumar
On Mon, 2 Nov 2020 17:10:34 GMT, Naoto Sato  wrote:

>> Hi Guys,
>> 
>> Please review the integration of tzdata2020d to JDK.
>> 
>> Details regarding the change can be viewed at - 
>> https://mm.icann.org/pipermail/tz-announce/2020-October/62.html
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8255226
>> 
>> TestZoneInfo310.java test failure is addressed along with it. The last rule 
>> affects "Asia/Gaza" and "Asia/Hebron" and therefore excluded from the test.
>> 
>> Regression Tests pass along with JCK.
>> 
>> Please let me know if the changes are good to push.
>> 
>> Thanks,
>> Kiran
>
> 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  2020max -   Mar Sat>=24 0:001:00S
Rule Palestine  2020max -   Oct Sat>=24 1:000   -

The failure seen is 

**
Asia/Gaza : Asia/Gaza
-
SimpleTimeZone (NG)
   
stz=java.util.SimpleTimeZone[id=Asia/Gaza,offset=720,dstSavings=360,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=360,endTimeMode=0]
  
stz0=java.util.SimpleTimeZone[id=Asia/Gaza,offset=720,dstSavings=360,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=360,endTimeMode=0]

-

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


Re: RFR: 8255226: (tz) Upgrade time-zone data to tzdata2020d

2020-11-02 Thread Naoto Sato
On Mon, 2 Nov 2020 16:29:07 GMT, Kiran Sidhartha Ravikumar 
 wrote:

> Hi Guys,
> 
> Please review the integration of tzdata2020d to JDK.
> 
> Details regarding the change can be viewed at - 
> https://mm.icann.org/pipermail/tz-announce/2020-October/62.html
> Bug: https://bugs.openjdk.java.net/browse/JDK-8255226
> 
> TestZoneInfo310.java test failure is addressed along with it. The last rule 
> affects "Asia/Gaza" and "Asia/Hebron" and therefore excluded from the test.
> 
> Regression Tests pass along with JCK.
> 
> Please let me know if the changes are good to push.
> 
> Thanks,
> Kiran

The test case needs copyright year change to 2020.

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.

-

Changes requested by naoto (Reviewer).

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


RFR: 8255226: (tz) Upgrade time-zone data to tzdata2020d

2020-11-02 Thread Kiran Sidhartha Ravikumar
Hi Guys,

Please review the integration of tzdata2020d to JDK.

Details regarding the change can be viewed at - 
https://mm.icann.org/pipermail/tz-announce/2020-October/62.html
Bug: https://bugs.openjdk.java.net/browse/JDK-8255226

TestZoneInfo310.java test failure is addressed along with it. The last rule 
affects "Asia/Gaza" and "Asia/Hebron" and therefore excluded from the test.

Regression Tests pass along with JCK.

Please let me know if the changes are good to push.

Thanks,
Kiran

-

Commit messages:
 - 8255226: (tz) Upgrade time-zone data to tzdata2020d

Changes: https://git.openjdk.java.net/jdk/pull/1012/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk=1012=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8255226
  Stats: 54 lines in 4 files changed: 34 ins; 2 del; 18 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1012.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1012/head:pull/1012

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