From rachna.goel at oracle.com  Tue Dec  1 06:55:13 2015
From: rachna.goel at oracle.com (Rachna Goel)
Date: Tue, 1 Dec 2015 12:25:13 +0530
Subject: <i18n dev> Review Request: JDK-8130246: PropertiesTest.sh fails..
Message-ID: <565D4451.6030601@oracle.com>

Hi all,

Please review the following fix in PropertiesTest.sh (JTREG test case 
for Currency).

Bug : https://bugs.openjdk.java.net/browse/JDK-8130246

webrev : http://cr.openjdk.java.net/~rgoel/8130246/webrev.01/
<http://cr.openjdk.java.net/%7Ergoel/8130246/webrev.01/>
Fix : Test case was updated to be sequential, removed Process spawning 
part of it.

Thanks,
Rachna

From naoto.sato at oracle.com  Tue Dec  1 17:51:40 2015
From: naoto.sato at oracle.com (Naoto Sato)
Date: Tue, 1 Dec 2015 09:51:40 -0800
Subject: <i18n dev> Review Request: JDK-8130246: PropertiesTest.sh
	fails..
In-Reply-To: <565D4451.6030601@oracle.com>
References: <565D4451.6030601@oracle.com>
Message-ID: <565DDE2C.6010509@oracle.com>

Looks good. Please add "noreg-self" label to the issue.

Naoto

On 11/30/15 10:55 PM, Rachna Goel wrote:
> Hi all,
>
> Please review the following fix in PropertiesTest.sh (JTREG test case
> for Currency).
>
> Bug : https://bugs.openjdk.java.net/browse/JDK-8130246
>
> webrev : http://cr.openjdk.java.net/~rgoel/8130246/webrev.01/
> <http://cr.openjdk.java.net/%7Ergoel/8130246/webrev.01/>
> Fix : Test case was updated to be sequential, removed Process spawning
> part of it.
>
> Thanks,
> Rachna

From masayoshi.okutsu at oracle.com  Thu Dec  3 04:48:23 2015
From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu)
Date: Thu, 3 Dec 2015 13:48:23 +0900
Subject: <i18n dev> [9] RFR: 8141243: Unexpected timezone returned after
 parsing a date
In-Reply-To: <56528BCC.6080102@oracle.com>
References: <564ED8AC.3050309@oracle.com> <564F5F05.1010704@oracle.com>
	<56528BCC.6080102@oracle.com>
Message-ID: <565FC997.7060106@oracle.com>

Naoto and I discussed the preferred ordered map. We decided to add the 
following change to the fix. This additional change doesn't affect the 
behavior, though.

diff --git a/make/src/classes/build/tools/cldrconverter/ResourceBundleGenerator.java b/make/src/classes/build/tools/cldrconverter/ResourceBundleGenerator.java
--- a/make/src/classes/build/tools/cldrconverter/ResourceBundleGenerator.java
+++ b/make/src/classes/build/tools/cldrconverter/ResourceBundleGenerator.java
...
@@ -136,7 +137,7 @@
              for (String preferred : preferredTZIDs) {
                  if (map.containsKey(preferred)) {
                      newMap.put(preferred, map.remove(preferred));
-                } else if ("GMT".equals(preferred) &&
+                } else if (("GMT".equals(preferred) || "UTC".equals(preferred)) &&
                             metaKeys.contains(CLDRConverter.METAZONE_ID_PREFIX+preferred)) {
                      newMap.put(preferred, preferred);
                  }

Thanks,
Masayoshi

On 11/23/2015 12:45 PM, Masayoshi Okutsu wrote:
> That part doesn't seem to affect UTC because it comes from the legacy 
> JRE locale data.
>
> Masayoshi
>
> On 11/21/2015 2:57 AM, Naoto Sato wrote:
>> In ResourceBundleGenerator.java, if we move "UTC" into the preferred 
>> names list, should we also treat it when we create the preferred 
>> ordered map? In other words, should we do the same for "UTC" at the 
>> line 140?
>>
>> Naoto
>>
>> On 11/20/15 12:24 AM, Masayoshi Okutsu wrote:
>>> Hello,
>>>
>>> This is a follow up of the fix for JDK-8141243 done by Ramanand. I've
>>> changed resources so that time zone ID "UTC" is picked up by
>>> SimpleDateFormat before Antarctica/Troll.
>>>
>>> issue: https://bugs.openjdk.java.net/browse/JDK-8141243
>>>
>>> webrev: http://cr.openjdk.java.net/~okutsu/9/8141243/webrev.00/
>>>
>>> Thanks,
>>> Masayoshi
>>>
>


From naoto.sato at oracle.com  Thu Dec  3 16:55:43 2015
From: naoto.sato at oracle.com (Naoto Sato)
Date: Thu, 3 Dec 2015 08:55:43 -0800
Subject: <i18n dev> [9] RFR: 8141243: Unexpected timezone returned after
 parsing a date
In-Reply-To: <565FC997.7060106@oracle.com>
References: <564ED8AC.3050309@oracle.com> <564F5F05.1010704@oracle.com>
	<56528BCC.6080102@oracle.com> <565FC997.7060106@oracle.com>
Message-ID: <5660740F.30908@oracle.com>

+1

Naoto

On 12/2/15 8:48 PM, Masayoshi Okutsu wrote:
> Naoto and I discussed the preferred ordered map. We decided to add the
> following change to the fix. This additional change doesn't affect the
> behavior, though.
>
> diff --git
> a/make/src/classes/build/tools/cldrconverter/ResourceBundleGenerator.java b/make/src/classes/build/tools/cldrconverter/ResourceBundleGenerator.java
>
> ---
> a/make/src/classes/build/tools/cldrconverter/ResourceBundleGenerator.java
> +++
> b/make/src/classes/build/tools/cldrconverter/ResourceBundleGenerator.java
> ...
> @@ -136,7 +137,7 @@
>               for (String preferred : preferredTZIDs) {
>                   if (map.containsKey(preferred)) {
>                       newMap.put(preferred, map.remove(preferred));
> -                } else if ("GMT".equals(preferred) &&
> +                } else if (("GMT".equals(preferred) ||
> "UTC".equals(preferred)) &&
>
> metaKeys.contains(CLDRConverter.METAZONE_ID_PREFIX+preferred)) {
>                       newMap.put(preferred, preferred);
>                   }
>
> Thanks,
> Masayoshi
>
> On 11/23/2015 12:45 PM, Masayoshi Okutsu wrote:
>> That part doesn't seem to affect UTC because it comes from the legacy
>> JRE locale data.
>>
>> Masayoshi
>>
>> On 11/21/2015 2:57 AM, Naoto Sato wrote:
>>> In ResourceBundleGenerator.java, if we move "UTC" into the preferred
>>> names list, should we also treat it when we create the preferred
>>> ordered map? In other words, should we do the same for "UTC" at the
>>> line 140?
>>>
>>> Naoto
>>>
>>> On 11/20/15 12:24 AM, Masayoshi Okutsu wrote:
>>>> Hello,
>>>>
>>>> This is a follow up of the fix for JDK-8141243 done by Ramanand. I've
>>>> changed resources so that time zone ID "UTC" is picked up by
>>>> SimpleDateFormat before Antarctica/Troll.
>>>>
>>>> issue: https://bugs.openjdk.java.net/browse/JDK-8141243
>>>>
>>>> webrev: http://cr.openjdk.java.net/~okutsu/9/8141243/webrev.00/
>>>>
>>>> Thanks,
>>>> Masayoshi
>>>>
>>
>

From rachna.goel at oracle.com  Wed Dec  9 07:09:41 2015
From: rachna.goel at oracle.com (Rachna Goel)
Date: Wed, 9 Dec 2015 12:39:41 +0530
Subject: <i18n dev> Review Request:JDK-8025547-Locale.toString()
	documentation error.
Message-ID: <5667D3B5.7040405@oracle.com>

Hi all,

Kindly review small documentation fix in Locale.toString() method.

Bug : https://bugs.openjdk.java.net/browse/JDK-8025547

webrev: http://cr.openjdk.java.net/~rgoel/8025547/webrev.02/ 
<http://cr.openjdk.java.net/%7Ergoel/8025547/webrev.02/>

Fix: updated documentation of Locale.tostring() method to reflect '_' 
character instead of '-' in between script and extension fields of 
Locale string.

-- 
Thanks,
Rachna


From ramanand.patil at oracle.com  Wed Dec  9 07:44:42 2015
From: ramanand.patil at oracle.com (Ramanand Patil)
Date: Tue, 8 Dec 2015 23:44:42 -0800 (PST)
Subject: <i18n dev> Review request for JDK-8066982: ZonedDateTime.parse()
 returns wrong ZoneOffset around DST fall transition
Message-ID: <75b86334-1d29-4889-b9ae-e2815462d711@default>

HI all,

 

Please review a fix for Bug  - HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8066982"JDK-8066982

 

Bug - Parsing a string with ZonedDateTime.parse() that contains zone offset and zone ID "Europe/Berlin" returns a wrong ZonedDateAndTime (different offset). This error starts exactly at the transition time (included) and ends one hour later (excluded).

 

Webrev - http://cr.openjdk.java.net/~aefimov/8066982/webrev.00/

 

One existing test case in TCKZonedDateTime.java is also modified, because - when offset is invalid the local time is changed to make the result valid.

 

 

Regards,

Ramanand.

From masayoshi.okutsu at oracle.com  Wed Dec  9 08:23:52 2015
From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu)
Date: Wed, 9 Dec 2015 17:23:52 +0900
Subject: <i18n dev> Review Request:JDK-8025547-Locale.toString()
 documentation error.
In-Reply-To: <5667D3B5.7040405@oracle.com>
References: <5667D3B5.7040405@oracle.com>
Message-ID: <5667E518.9080203@oracle.com>

Looks good to me.

Masayoshi

On 12/9/2015 4:09 PM, Rachna Goel wrote:
> Hi all,
>
> Kindly review small documentation fix in Locale.toString() method.
>
> Bug : https://bugs.openjdk.java.net/browse/JDK-8025547
>
> webrev: http://cr.openjdk.java.net/~rgoel/8025547/webrev.02/ 
> <http://cr.openjdk.java.net/%7Ergoel/8025547/webrev.02/>
>
> Fix: updated documentation of Locale.tostring() method to reflect '_' 
> character instead of '-' in between script and extension fields of 
> Locale string.
>


From scolebourne at joda.org  Wed Dec  9 11:15:59 2015
From: scolebourne at joda.org (Stephen Colebourne)
Date: Wed, 9 Dec 2015 11:15:59 +0000
Subject: <i18n dev> Review request for JDK-8066982:
 ZonedDateTime.parse() returns wrong ZoneOffset around DST fall transition
In-Reply-To: <75b86334-1d29-4889-b9ae-e2815462d711@default>
References: <75b86334-1d29-4889-b9ae-e2815462d711@default>
Message-ID: <CACzrW9DWO46818MJJ46yp8cdFt69QNN=-pCK93N-Fru1bmgikA@mail.gmail.com>

The logic looks fine.

In the main code, this part
  .getLong(INSTANT_SECONDS);
can be replaced with
  .toEpochSecond();
which will be slightly faster.

In the test case, this part
 .plus(15, ChronoUnit.MINUTES);
can be replaced with
 .plusMinutes(15)

And
 .with(ChronoField.OFFSET_SECONDS,
ZoneOffset.of(offsetSamples[j]).getTotalSeconds())
can be replaced with
 .with(ZoneOffset.of(offsetSamples[j]))

In addition to the looping tests, I'd like to see the examples from
the bug report as test cases. Those tests would be simple to follow
and explain, whereas the looping tests are a little hard to follow.

thanks for fixing this
Stephen



On 9 December 2015 at 07:44, Ramanand Patil <ramanand.patil at oracle.com> wrote:
> HI all,
>
>
>
> Please review a fix for Bug  - HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8066982"JDK-8066982
>
>
>
> Bug - Parsing a string with ZonedDateTime.parse() that contains zone offset and zone ID "Europe/Berlin" returns a wrong ZonedDateAndTime (different offset). This error starts exactly at the transition time (included) and ends one hour later (excluded).
>
>
>
> Webrev - http://cr.openjdk.java.net/~aefimov/8066982/webrev.00/
>
>
>
> One existing test case in TCKZonedDateTime.java is also modified, because - when offset is invalid the local time is changed to make the result valid.
>
>
>
>
>
> Regards,
>
> Ramanand.

From naoto.sato at oracle.com  Wed Dec  9 18:26:52 2015
From: naoto.sato at oracle.com (Naoto Sato)
Date: Wed, 9 Dec 2015 10:26:52 -0800
Subject: <i18n dev> Review Request:JDK-8025547-Locale.toString()
 documentation error.
In-Reply-To: <5667E518.9080203@oracle.com>
References: <5667D3B5.7040405@oracle.com> <5667E518.9080203@oracle.com>
Message-ID: <5668726C.3070304@oracle.com>

+1

Naoto

On 12/9/15 12:23 AM, Masayoshi Okutsu wrote:
> Looks good to me.
>
> Masayoshi
>
> On 12/9/2015 4:09 PM, Rachna Goel wrote:
>> Hi all,
>>
>> Kindly review small documentation fix in Locale.toString() method.
>>
>> Bug : https://bugs.openjdk.java.net/browse/JDK-8025547
>>
>> webrev: http://cr.openjdk.java.net/~rgoel/8025547/webrev.02/
>> <http://cr.openjdk.java.net/%7Ergoel/8025547/webrev.02/>
>>
>> Fix: updated documentation of Locale.tostring() method to reflect '_'
>> character instead of '-' in between script and extension fields of
>> Locale string.
>>
>

From ramanand.patil at oracle.com  Thu Dec 10 15:36:02 2015
From: ramanand.patil at oracle.com (Ramanand Patil)
Date: Thu, 10 Dec 2015 07:36:02 -0800 (PST)
Subject: <i18n dev> Review request for JDK-8066982:
 ZonedDateTime.parse() returns wrong ZoneOffset around DST fall transition
In-Reply-To: <CACzrW9DWO46818MJJ46yp8cdFt69QNN=-pCK93N-Fru1bmgikA@mail.gmail.com>
References: <75b86334-1d29-4889-b9ae-e2815462d711@default>
	<CACzrW9DWO46818MJJ46yp8cdFt69QNN=-pCK93N-Fru1bmgikA@mail.gmail.com>
Message-ID: <47f03ddd-1c77-4697-9ce1-f14b9d9547b7@default>

Hi all,

Please review the updated webrev: http://cr.openjdk.java.net/~aefimov/8066982/webrev.01/

I have modified the fix and test cases as per inputs given by Stephen. Also, I have added the javadocs changes in this patch which were proposed in the bug.

Bug link is: https://bugs.openjdk.java.net/browse/JDK-8066982


Regards,
Ramanand.

-----Original Message-----
From: Stephen Colebourne [mailto:scolebourne at joda.org] 
Sent: Wednesday, December 09, 2015 4:46 PM
To: core-libs-dev
Cc: i18n-dev
Subject: Re: <i18n dev> Review request for JDK-8066982: ZonedDateTime.parse() returns wrong ZoneOffset around DST fall transition

The logic looks fine.

In the main code, this part
  .getLong(INSTANT_SECONDS);
can be replaced with
  .toEpochSecond();
which will be slightly faster.

In the test case, this part
 .plus(15, ChronoUnit.MINUTES);
can be replaced with
 .plusMinutes(15)

And
 .with(ChronoField.OFFSET_SECONDS,
ZoneOffset.of(offsetSamples[j]).getTotalSeconds())
can be replaced with
 .with(ZoneOffset.of(offsetSamples[j]))

In addition to the looping tests, I'd like to see the examples from the bug report as test cases. Those tests would be simple to follow and explain, whereas the looping tests are a little hard to follow.

thanks for fixing this
Stephen



On 9 December 2015 at 07:44, Ramanand Patil <ramanand.patil at oracle.com> wrote:
> HI all,
>
>
>
> Please review a fix for Bug  - HYPERLINK 
> "https://bugs.openjdk.java.net/browse/JDK-8066982"JDK-8066982
>
>
>
> Bug - Parsing a string with ZonedDateTime.parse() that contains zone offset and zone ID "Europe/Berlin" returns a wrong ZonedDateAndTime (different offset). This error starts exactly at the transition time (included) and ends one hour later (excluded).
>
>
>
> Webrev - http://cr.openjdk.java.net/~aefimov/8066982/webrev.00/
>
>
>
> One existing test case in TCKZonedDateTime.java is also modified, because - when offset is invalid the local time is changed to make the result valid.
>
>
>
>
>
> Regards,
>
> Ramanand.

From scolebourne at joda.org  Thu Dec 10 16:00:12 2015
From: scolebourne at joda.org (Stephen Colebourne)
Date: Thu, 10 Dec 2015 16:00:12 +0000
Subject: <i18n dev> Review request for JDK-8066982:
 ZonedDateTime.parse() returns wrong ZoneOffset around DST fall transition
In-Reply-To: <47f03ddd-1c77-4697-9ce1-f14b9d9547b7@default>
References: <75b86334-1d29-4889-b9ae-e2815462d711@default>
	<CACzrW9DWO46818MJJ46yp8cdFt69QNN=-pCK93N-Fru1bmgikA@mail.gmail.com>
	<47f03ddd-1c77-4697-9ce1-f14b9d9547b7@default>
Message-ID: <CACzrW9DhDBi-kv2Hb6oCao26dpL3ZqHTse59QyXU75Q2mg7RSQ@mail.gmail.com>

I believe this is suitable for committing, thanks, other reviews welcome!
Stephen



On 10 December 2015 at 15:36, Ramanand Patil <ramanand.patil at oracle.com> wrote:
> Hi all,
>
> Please review the updated webrev: http://cr.openjdk.java.net/~aefimov/8066982/webrev.01/
>
> I have modified the fix and test cases as per inputs given by Stephen. Also, I have added the javadocs changes in this patch which were proposed in the bug.
>
> Bug link is: https://bugs.openjdk.java.net/browse/JDK-8066982
>
>
> Regards,
> Ramanand.
>
> -----Original Message-----
> From: Stephen Colebourne [mailto:scolebourne at joda.org]
> Sent: Wednesday, December 09, 2015 4:46 PM
> To: core-libs-dev
> Cc: i18n-dev
> Subject: Re: <i18n dev> Review request for JDK-8066982: ZonedDateTime.parse() returns wrong ZoneOffset around DST fall transition
>
> The logic looks fine.
>
> In the main code, this part
>   .getLong(INSTANT_SECONDS);
> can be replaced with
>   .toEpochSecond();
> which will be slightly faster.
>
> In the test case, this part
>  .plus(15, ChronoUnit.MINUTES);
> can be replaced with
>  .plusMinutes(15)
>
> And
>  .with(ChronoField.OFFSET_SECONDS,
> ZoneOffset.of(offsetSamples[j]).getTotalSeconds())
> can be replaced with
>  .with(ZoneOffset.of(offsetSamples[j]))
>
> In addition to the looping tests, I'd like to see the examples from the bug report as test cases. Those tests would be simple to follow and explain, whereas the looping tests are a little hard to follow.
>
> thanks for fixing this
> Stephen
>
>
>
> On 9 December 2015 at 07:44, Ramanand Patil <ramanand.patil at oracle.com> wrote:
>> HI all,
>>
>>
>>
>> Please review a fix for Bug  - HYPERLINK
>> "https://bugs.openjdk.java.net/browse/JDK-8066982"JDK-8066982
>>
>>
>>
>> Bug - Parsing a string with ZonedDateTime.parse() that contains zone offset and zone ID "Europe/Berlin" returns a wrong ZonedDateAndTime (different offset). This error starts exactly at the transition time (included) and ends one hour later (excluded).
>>
>>
>>
>> Webrev - http://cr.openjdk.java.net/~aefimov/8066982/webrev.00/
>>
>>
>>
>> One existing test case in TCKZonedDateTime.java is also modified, because - when offset is invalid the local time is changed to make the result valid.
>>
>>
>>
>>
>>
>> Regards,
>>
>> Ramanand.

From Roger.Riggs at Oracle.com  Fri Dec 11 20:07:26 2015
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Fri, 11 Dec 2015 15:07:26 -0500
Subject: <i18n dev> Review request for JDK-8066982:
 ZonedDateTime.parse() returns wrong ZoneOffset around DST fall transition
In-Reply-To: <CACzrW9DhDBi-kv2Hb6oCao26dpL3ZqHTse59QyXU75Q2mg7RSQ@mail.gmail.com>
References: <75b86334-1d29-4889-b9ae-e2815462d711@default>
	<CACzrW9DWO46818MJJ46yp8cdFt69QNN=-pCK93N-Fru1bmgikA@mail.gmail.com>
	<47f03ddd-1c77-4697-9ce1-f14b9d9547b7@default>
	<CACzrW9DhDBi-kv2Hb6oCao26dpL3ZqHTse59QyXU75Q2mg7RSQ@mail.gmail.com>
Message-ID: <566B2CFE.3030802@Oracle.com>

Hi,

Stephen, can you  confirm that the added text and test in 
DateTimeFormatter is not a specification change?
Our processes have a bit more to do if it is a spec change and it would 
limit the backport to JDK 8.

This bug fix will cause an existing TCK/JCK test to fail but that is 
considered also a bug and is fixed.
     test/java/time/tck/java/time/TCKZonedDateTime.java

Ramanand, some comments on the new test:
  - The 'private' qualifier on the tests and data providers is not used 
in the current tests and
     is not consistently present in the new one.
     Since it has little/no function, the tests would be a bit cleaner 
without it.

  - Typically, test that have data dependencies (such as the timezone 
data) cannot be used for
     compatibility to the specification, but the data is stable and it 
seems unavoidable in this case.

  - Are all of the data cases necessary to validate the specification?
    Redundant cases extend the testing time without adding more 
confidence to the quality.

Thanks,  Roger


On 12/10/2015 11:00 AM, Stephen Colebourne wrote:
> I believe this is suitable for committing, thanks, other reviews welcome!
> Stephen
>
>
>
> On 10 December 2015 at 15:36, Ramanand Patil <ramanand.patil at oracle.com> wrote:
>> Hi all,
>>
>> Please review the updated webrev: http://cr.openjdk.java.net/~aefimov/8066982/webrev.01/
>>
>> I have modified the fix and test cases as per inputs given by Stephen. Also, I have added the javadocs changes in this patch which were proposed in the bug.
>>
>> Bug link is: https://bugs.openjdk.java.net/browse/JDK-8066982
>>
>>
>> Regards,
>> Ramanand.
>>
>> -----Original Message-----
>> From: Stephen Colebourne [mailto:scolebourne at joda.org]
>> Sent: Wednesday, December 09, 2015 4:46 PM
>> To: core-libs-dev
>> Cc: i18n-dev
>> Subject: Re: <i18n dev> Review request for JDK-8066982: ZonedDateTime.parse() returns wrong ZoneOffset around DST fall transition
>>
>> The logic looks fine.
>>
>> In the main code, this part
>>    .getLong(INSTANT_SECONDS);
>> can be replaced with
>>    .toEpochSecond();
>> which will be slightly faster.
>>
>> In the test case, this part
>>   .plus(15, ChronoUnit.MINUTES);
>> can be replaced with
>>   .plusMinutes(15)
>>
>> And
>>   .with(ChronoField.OFFSET_SECONDS,
>> ZoneOffset.of(offsetSamples[j]).getTotalSeconds())
>> can be replaced with
>>   .with(ZoneOffset.of(offsetSamples[j]))
>>
>> In addition to the looping tests, I'd like to see the examples from the bug report as test cases. Those tests would be simple to follow and explain, whereas the looping tests are a little hard to follow.
>>
>> thanks for fixing this
>> Stephen
>>
>>
>>
>> On 9 December 2015 at 07:44, Ramanand Patil <ramanand.patil at oracle.com> wrote:
>>> HI all,
>>>
>>>
>>>
>>> Please review a fix for Bug  - HYPERLINK
>>> "https://bugs.openjdk.java.net/browse/JDK-8066982"JDK-8066982
>>>
>>>
>>>
>>> Bug - Parsing a string with ZonedDateTime.parse() that contains zone offset and zone ID "Europe/Berlin" returns a wrong ZonedDateAndTime (different offset). This error starts exactly at the transition time (included) and ends one hour later (excluded).
>>>
>>>
>>>
>>> Webrev - http://cr.openjdk.java.net/~aefimov/8066982/webrev.00/
>>>
>>>
>>>
>>> One existing test case in TCKZonedDateTime.java is also modified, because - when offset is invalid the local time is changed to make the result valid.
>>>
>>>
>>>
>>>
>>>
>>> Regards,
>>>
>>> Ramanand.


From ramanand.patil at oracle.com  Mon Dec 14 08:14:13 2015
From: ramanand.patil at oracle.com (Ramanand Patil)
Date: Mon, 14 Dec 2015 00:14:13 -0800 (PST)
Subject: <i18n dev> Review request for JDK-8066982:
 ZonedDateTime.parse() returns wrong ZoneOffset around DST fall transition
In-Reply-To: <566B2CFE.3030802@Oracle.com>
References: <75b86334-1d29-4889-b9ae-e2815462d711@default>
	<CACzrW9DWO46818MJJ46yp8cdFt69QNN=-pCK93N-Fru1bmgikA@mail.gmail.com>
	<47f03ddd-1c77-4697-9ce1-f14b9d9547b7@default>
	<CACzrW9DhDBi-kv2Hb6oCao26dpL3ZqHTse59QyXU75Q2mg7RSQ@mail.gmail.com>
	<566B2CFE.3030802@Oracle.com>
Message-ID: <96b1ddd9-e543-42e5-8597-9b466225f854@default>

Hi Roger and all,

Please review the updated Webrev: http://cr.openjdk.java.net/~ntv/ramanand/8066982/webrev.02/

Bug: https://bugs.openjdk.java.net/browse/JDK-8066982


Roger, please see my comments about new tests:

- All my test methods were earlier generic with main method and hence had private static qualifier. I have changed them now to match and to be consistent with the existing tests. Thank you for pointing this.

- I agree with you on this. Particularly when we have tests around DST we can?t avoid timezone data.

- I have defined dataProvider for every method and reduced the test data for cases where zone is not present(testWithoutZoneWithoutOffset() and testWithOffsetWithoutZone()). 
But for the other 2 cases where zone is present(testWithZoneWithOffset() and testWithZoneWithoutOffset()), I feel most of the data cases are necessary and some are required to be on safer side if in future the timezone rule changes. Also, this bug fix mainly affects these cases.
I have created the dataProvider kepping in mind the below cases for 2 DST zones.
1. Time before overlap
2. Time during Overlap
3. Time after overlap
4. Valid Offsets for each of these times
5. Zero Offset for each time
6. Few Positive and negative invalid offsets for each time


Regards,
Ramanand.


-----Original Message-----
From: Roger Riggs 
Sent: Saturday, December 12, 2015 1:37 AM
To:  HYPERLINK "mailto:core-libs-dev at openjdk.java.net" core-libs-dev at openjdk.java.net
Cc:  HYPERLINK "mailto:i18n-dev at openjdk.java.net" i18n-dev at openjdk.java.net
Subject: Re: <i18n dev> Review request for JDK-8066982: ZonedDateTime.parse() returns wrong ZoneOffset around DST fall transition

Hi,

Stephen, can you  confirm that the added text and test in DateTimeFormatter is not a specification change?
Our processes have a bit more to do if it is a spec change and it would limit the backport to JDK 8.

This bug fix will cause an existing TCK/JCK test to fail but that is considered also a bug and is fixed.
     test/java/time/tck/java/time/TCKZonedDateTime.java

Ramanand, some comments on the new test:
  - The 'private' qualifier on the tests and data providers is not used in the current tests and
     is not consistently present in the new one.
     Since it has little/no function, the tests would be a bit cleaner without it.

  - Typically, test that have data dependencies (such as the timezone
data) cannot be used for
     compatibility to the specification, but the data is stable and it seems unavoidable in this case.

  - Are all of the data cases necessary to validate the specification?
    Redundant cases extend the testing time without adding more confidence to the quality.

Thanks,  Roger


On 12/10/2015 11:00 AM, Stephen Colebourne wrote:
> I believe this is suitable for committing, thanks, other reviews welcome!
> Stephen
>
>
>
> On 10 December 2015 at 15:36, Ramanand Patil < HYPERLINK "mailto:ramanand.patil at oracle.com" ramanand.patil at oracle.com> wrote:
>> Hi all,
>>
>> Please review the updated webrev: 
>> http://cr.openjdk.java.net/~aefimov/8066982/webrev.01/
>>
>> I have modified the fix and test cases as per inputs given by Stephen. Also, I have added the javadocs changes in this patch which were proposed in the bug.
>>
>> Bug link is: https://bugs.openjdk.java.net/browse/JDK-8066982
>>
>>
>> Regards,
>> Ramanand.
>>
>> -----Original Message-----
>> From: Stephen Colebourne [mailto:scolebourne at joda.org]
>> Sent: Wednesday, December 09, 2015 4:46 PM
>> To: core-libs-dev
>> Cc: i18n-dev
>> Subject: Re: <i18n dev> Review request for JDK-8066982: 
>> ZonedDateTime.parse() returns wrong ZoneOffset around DST fall 
>> transition
>>
>> The logic looks fine.
>>
>> In the main code, this part
>>    .getLong(INSTANT_SECONDS);
>> can be replaced with
>>    .toEpochSecond();
>> which will be slightly faster.
>>
>> In the test case, this part
>>   .plus(15, ChronoUnit.MINUTES);
>> can be replaced with
>>   .plusMinutes(15)
>>
>> And
>>   .with(ChronoField.OFFSET_SECONDS,
>> ZoneOffset.of(offsetSamples[j]).getTotalSeconds())
>> can be replaced with
>>   .with(ZoneOffset.of(offsetSamples[j]))
>>
>> In addition to the looping tests, I'd like to see the examples from the bug report as test cases. Those tests would be simple to follow and explain, whereas the looping tests are a little hard to follow.
>>
>> thanks for fixing this
>> Stephen
>>
>>
>>
>> On 9 December 2015 at 07:44, Ramanand Patil < HYPERLINK "mailto:ramanand.patil at oracle.com" ramanand.patil at oracle.com> wrote:
>>> HI all,
>>>
>>>
>>>
>>> Please review a fix for Bug  - HYPERLINK
>>> "https://bugs.openjdk.java.net/browse/JDK-8066982"JDK-8066982
>>>
>>>
>>>
>>> Bug - Parsing a string with ZonedDateTime.parse() that contains zone offset and zone ID "Europe/Berlin" returns a wrong ZonedDateAndTime (different offset). This error starts exactly at the transition time (included) and ends one hour later (excluded).
>>>
>>>
>>>
>>> Webrev - http://cr.openjdk.java.net/~aefimov/8066982/webrev.00/
>>>
>>>
>>>
>>> One existing test case in TCKZonedDateTime.java is also modified, because - when offset is invalid the local time is changed to make the result valid.
>>>
>>>
>>>
>>>
>>>
>>> Regards,
>>>
>>> Ramanand.


From scolebourne at joda.org  Mon Dec 14 09:20:55 2015
From: scolebourne at joda.org (Stephen Colebourne)
Date: Mon, 14 Dec 2015 09:20:55 +0000
Subject: <i18n dev> Review request for JDK-8066982:
 ZonedDateTime.parse() returns wrong ZoneOffset around DST fall transition
In-Reply-To: <566B2CFE.3030802@Oracle.com>
References: <75b86334-1d29-4889-b9ae-e2815462d711@default>
	<CACzrW9DWO46818MJJ46yp8cdFt69QNN=-pCK93N-Fru1bmgikA@mail.gmail.com>
	<47f03ddd-1c77-4697-9ce1-f14b9d9547b7@default>
	<CACzrW9DhDBi-kv2Hb6oCao26dpL3ZqHTse59QyXU75Q2mg7RSQ@mail.gmail.com>
	<566B2CFE.3030802@Oracle.com>
Message-ID: <CACzrW9B=e66pSXeHa+9wJ6iM0ML8=-vF_bFpmFwcTh4RhhqbKQ@mail.gmail.com>

The added text and tests represent a spec clarification. The behaviour
in this area was not precisely defined before. The bug itself was
clear due to the expected round-trip behaviour of toString() and
parse(). While this is a slightly more tricky backport than some, it
is really quite broken in one of the most important areas for a
date-time library, the DST overlap.

IMO, the two extra spec <li> elements probably should not be
backported. However the rest should be. I'm not sure whether the "TCK"
test classes are still used as the TCK, so it is possible that the
backport should have tests located in a different place.

Hope that helps
Stephen



On 11 December 2015 at 20:07, Roger Riggs <Roger.Riggs at oracle.com> wrote:
> Hi,
>
> Stephen, can you  confirm that the added text and test in DateTimeFormatter
> is not a specification change?
> Our processes have a bit more to do if it is a spec change and it would
> limit the backport to JDK 8.
>
> This bug fix will cause an existing TCK/JCK test to fail but that is
> considered also a bug and is fixed.
>     test/java/time/tck/java/time/TCKZonedDateTime.java
>
> Ramanand, some comments on the new test:
>  - The 'private' qualifier on the tests and data providers is not used in
> the current tests and
>     is not consistently present in the new one.
>     Since it has little/no function, the tests would be a bit cleaner
> without it.
>
>  - Typically, test that have data dependencies (such as the timezone data)
> cannot be used for
>     compatibility to the specification, but the data is stable and it seems
> unavoidable in this case.
>
>  - Are all of the data cases necessary to validate the specification?
>    Redundant cases extend the testing time without adding more confidence to
> the quality.
>
> Thanks,  Roger
>
>
>
> On 12/10/2015 11:00 AM, Stephen Colebourne wrote:
>>
>> I believe this is suitable for committing, thanks, other reviews welcome!
>> Stephen
>>
>>
>>
>> On 10 December 2015 at 15:36, Ramanand Patil <ramanand.patil at oracle.com>
>> wrote:
>>>
>>> Hi all,
>>>
>>> Please review the updated webrev:
>>> http://cr.openjdk.java.net/~aefimov/8066982/webrev.01/
>>>
>>> I have modified the fix and test cases as per inputs given by Stephen.
>>> Also, I have added the javadocs changes in this patch which were proposed in
>>> the bug.
>>>
>>> Bug link is: https://bugs.openjdk.java.net/browse/JDK-8066982
>>>
>>>
>>> Regards,
>>> Ramanand.
>>>
>>> -----Original Message-----
>>> From: Stephen Colebourne [mailto:scolebourne at joda.org]
>>> Sent: Wednesday, December 09, 2015 4:46 PM
>>> To: core-libs-dev
>>> Cc: i18n-dev
>>> Subject: Re: <i18n dev> Review request for JDK-8066982:
>>> ZonedDateTime.parse() returns wrong ZoneOffset around DST fall transition
>>>
>>> The logic looks fine.
>>>
>>> In the main code, this part
>>>    .getLong(INSTANT_SECONDS);
>>> can be replaced with
>>>    .toEpochSecond();
>>> which will be slightly faster.
>>>
>>> In the test case, this part
>>>   .plus(15, ChronoUnit.MINUTES);
>>> can be replaced with
>>>   .plusMinutes(15)
>>>
>>> And
>>>   .with(ChronoField.OFFSET_SECONDS,
>>> ZoneOffset.of(offsetSamples[j]).getTotalSeconds())
>>> can be replaced with
>>>   .with(ZoneOffset.of(offsetSamples[j]))
>>>
>>> In addition to the looping tests, I'd like to see the examples from the
>>> bug report as test cases. Those tests would be simple to follow and explain,
>>> whereas the looping tests are a little hard to follow.
>>>
>>> thanks for fixing this
>>> Stephen
>>>
>>>
>>>
>>> On 9 December 2015 at 07:44, Ramanand Patil <ramanand.patil at oracle.com>
>>> wrote:
>>>>
>>>> HI all,
>>>>
>>>>
>>>>
>>>> Please review a fix for Bug  - HYPERLINK
>>>> "https://bugs.openjdk.java.net/browse/JDK-8066982"JDK-8066982
>>>>
>>>>
>>>>
>>>> Bug - Parsing a string with ZonedDateTime.parse() that contains zone
>>>> offset and zone ID "Europe/Berlin" returns a wrong ZonedDateAndTime
>>>> (different offset). This error starts exactly at the transition time
>>>> (included) and ends one hour later (excluded).
>>>>
>>>>
>>>>
>>>> Webrev - http://cr.openjdk.java.net/~aefimov/8066982/webrev.00/
>>>>
>>>>
>>>>
>>>> One existing test case in TCKZonedDateTime.java is also modified,
>>>> because - when offset is invalid the local time is changed to make the
>>>> result valid.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Regards,
>>>>
>>>> Ramanand.
>
>

From scolebourne at joda.org  Mon Dec 14 09:21:48 2015
From: scolebourne at joda.org (Stephen Colebourne)
Date: Mon, 14 Dec 2015 09:21:48 +0000
Subject: <i18n dev> Review request for JDK-8066982:
 ZonedDateTime.parse() returns wrong ZoneOffset around DST fall transition
In-Reply-To: <96b1ddd9-e543-42e5-8597-9b466225f854@default>
References: <75b86334-1d29-4889-b9ae-e2815462d711@default>
	<CACzrW9DWO46818MJJ46yp8cdFt69QNN=-pCK93N-Fru1bmgikA@mail.gmail.com>
	<47f03ddd-1c77-4697-9ce1-f14b9d9547b7@default>
	<CACzrW9DhDBi-kv2Hb6oCao26dpL3ZqHTse59QyXU75Q2mg7RSQ@mail.gmail.com>
	<566B2CFE.3030802@Oracle.com>
	<96b1ddd9-e543-42e5-8597-9b466225f854@default>
Message-ID: <CACzrW9AjoxdkF5wRdhjPPPN_xKUUj9mjCVx19g+XFChwArF0cA@mail.gmail.com>

I remain happy with the webrev
Stephen

On 14 December 2015 at 08:14, Ramanand Patil <ramanand.patil at oracle.com> wrote:
> Hi Roger and all,
>
> Please review the updated Webrev: http://cr.openjdk.java.net/~ntv/ramanand/8066982/webrev.02/
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8066982
>
>
> Roger, please see my comments about new tests:
>
> - All my test methods were earlier generic with main method and hence had private static qualifier. I have changed them now to match and to be consistent with the existing tests. Thank you for pointing this.
>
> - I agree with you on this. Particularly when we have tests around DST we can?t avoid timezone data.
>
> - I have defined dataProvider for every method and reduced the test data for cases where zone is not present(testWithoutZoneWithoutOffset() and testWithOffsetWithoutZone()).
> But for the other 2 cases where zone is present(testWithZoneWithOffset() and testWithZoneWithoutOffset()), I feel most of the data cases are necessary and some are required to be on safer side if in future the timezone rule changes. Also, this bug fix mainly affects these cases.
> I have created the dataProvider kepping in mind the below cases for 2 DST zones.
> 1. Time before overlap
> 2. Time during Overlap
> 3. Time after overlap
> 4. Valid Offsets for each of these times
> 5. Zero Offset for each time
> 6. Few Positive and negative invalid offsets for each time
>
>
> Regards,
> Ramanand.
>
>
> -----Original Message-----
> From: Roger Riggs
> Sent: Saturday, December 12, 2015 1:37 AM
> To:  HYPERLINK "mailto:core-libs-dev at openjdk.java.net" core-libs-dev at openjdk.java.net
> Cc:  HYPERLINK "mailto:i18n-dev at openjdk.java.net" i18n-dev at openjdk.java.net
> Subject: Re: <i18n dev> Review request for JDK-8066982: ZonedDateTime.parse() returns wrong ZoneOffset around DST fall transition
>
> Hi,
>
> Stephen, can you  confirm that the added text and test in DateTimeFormatter is not a specification change?
> Our processes have a bit more to do if it is a spec change and it would limit the backport to JDK 8.
>
> This bug fix will cause an existing TCK/JCK test to fail but that is considered also a bug and is fixed.
>      test/java/time/tck/java/time/TCKZonedDateTime.java
>
> Ramanand, some comments on the new test:
>   - The 'private' qualifier on the tests and data providers is not used in the current tests and
>      is not consistently present in the new one.
>      Since it has little/no function, the tests would be a bit cleaner without it.
>
>   - Typically, test that have data dependencies (such as the timezone
> data) cannot be used for
>      compatibility to the specification, but the data is stable and it seems unavoidable in this case.
>
>   - Are all of the data cases necessary to validate the specification?
>     Redundant cases extend the testing time without adding more confidence to the quality.
>
> Thanks,  Roger
>
>
> On 12/10/2015 11:00 AM, Stephen Colebourne wrote:
>> I believe this is suitable for committing, thanks, other reviews welcome!
>> Stephen
>>
>>
>>
>> On 10 December 2015 at 15:36, Ramanand Patil < HYPERLINK "mailto:ramanand.patil at oracle.com" ramanand.patil at oracle.com> wrote:
>>> Hi all,
>>>
>>> Please review the updated webrev:
>>> http://cr.openjdk.java.net/~aefimov/8066982/webrev.01/
>>>
>>> I have modified the fix and test cases as per inputs given by Stephen. Also, I have added the javadocs changes in this patch which were proposed in the bug.
>>>
>>> Bug link is: https://bugs.openjdk.java.net/browse/JDK-8066982
>>>
>>>
>>> Regards,
>>> Ramanand.
>>>
>>> -----Original Message-----
>>> From: Stephen Colebourne [mailto:scolebourne at joda.org]
>>> Sent: Wednesday, December 09, 2015 4:46 PM
>>> To: core-libs-dev
>>> Cc: i18n-dev
>>> Subject: Re: <i18n dev> Review request for JDK-8066982:
>>> ZonedDateTime.parse() returns wrong ZoneOffset around DST fall
>>> transition
>>>
>>> The logic looks fine.
>>>
>>> In the main code, this part
>>>    .getLong(INSTANT_SECONDS);
>>> can be replaced with
>>>    .toEpochSecond();
>>> which will be slightly faster.
>>>
>>> In the test case, this part
>>>   .plus(15, ChronoUnit.MINUTES);
>>> can be replaced with
>>>   .plusMinutes(15)
>>>
>>> And
>>>   .with(ChronoField.OFFSET_SECONDS,
>>> ZoneOffset.of(offsetSamples[j]).getTotalSeconds())
>>> can be replaced with
>>>   .with(ZoneOffset.of(offsetSamples[j]))
>>>
>>> In addition to the looping tests, I'd like to see the examples from the bug report as test cases. Those tests would be simple to follow and explain, whereas the looping tests are a little hard to follow.
>>>
>>> thanks for fixing this
>>> Stephen
>>>
>>>
>>>
>>> On 9 December 2015 at 07:44, Ramanand Patil < HYPERLINK "mailto:ramanand.patil at oracle.com" ramanand.patil at oracle.com> wrote:
>>>> HI all,
>>>>
>>>>
>>>>
>>>> Please review a fix for Bug  - HYPERLINK
>>>> "https://bugs.openjdk.java.net/browse/JDK-8066982"JDK-8066982
>>>>
>>>>
>>>>
>>>> Bug - Parsing a string with ZonedDateTime.parse() that contains zone offset and zone ID "Europe/Berlin" returns a wrong ZonedDateAndTime (different offset). This error starts exactly at the transition time (included) and ends one hour later (excluded).
>>>>
>>>>
>>>>
>>>> Webrev - http://cr.openjdk.java.net/~aefimov/8066982/webrev.00/
>>>>
>>>>
>>>>
>>>> One existing test case in TCKZonedDateTime.java is also modified, because - when offset is invalid the local time is changed to make the result valid.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Regards,
>>>>
>>>> Ramanand.
>

From naveen.ah.kumar at oracle.com  Mon Dec 14 09:29:32 2015
From: naveen.ah.kumar at oracle.com (Naveen Kumar)
Date: Mon, 14 Dec 2015 14:59:32 +0530
Subject: <i18n dev> Review Request: JDK-8139572 SimpleDateFormat parse month
 stand-alone format bug
Message-ID: <566E8BFB.7050607@oracle.com>

Hi All,
            Please review the following fix for jdk9.

Bug: https://bugs.openjdk.java.net/browse/JDK-8139572
webrev: http://cr.openjdk.java.net/~okutsu/naveen/8139572/webrev.00/

issue description:
SimpleDateFormat with "stand-alone" month format "LLLL yyyy" and locate 
ru_RU throw java.text.ParseExceptio when parse the valid date string 
"???????? 2015".

Fix:
Implemented parsing for "stand-alone" month format pattern in 
jdk/src/java.base/share/classes/java/text/SimpleDateFormat.java


regards
Naveen Kumar

From masayoshi.okutsu at oracle.com  Mon Dec 14 09:44:02 2015
From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu)
Date: Mon, 14 Dec 2015 18:44:02 +0900
Subject: <i18n dev> Review Request: JDK-8139572 SimpleDateFormat parse
 month stand-alone format bug
In-Reply-To: <566E8BFB.7050607@oracle.com>
References: <566E8BFB.7050607@oracle.com>
Message-ID: <566E8F62.7010400@oracle.com>

Looks good to me.

Masayoshi

On 12/14/2015 6:29 PM, Naveen Kumar wrote:
> Hi All,
>            Please review the following fix for jdk9.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8139572
> webrev: http://cr.openjdk.java.net/~okutsu/naveen/8139572/webrev.00/
>
> issue description:
> SimpleDateFormat with "stand-alone" month format "LLLL yyyy" and 
> locate ru_RU throw java.text.ParseExceptio when parse the valid date 
> string "???????? 2015".
>
> Fix:
> Implemented parsing for "stand-alone" month format pattern in 
> jdk/src/java.base/share/classes/java/text/SimpleDateFormat.java
>
>
> regards
> Naveen Kumar


From Roger.Riggs at Oracle.com  Mon Dec 14 15:06:01 2015
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Mon, 14 Dec 2015 10:06:01 -0500
Subject: <i18n dev> Review request for JDK-8066982:
 ZonedDateTime.parse() returns wrong ZoneOffset around DST fall transition
In-Reply-To: <96b1ddd9-e543-42e5-8597-9b466225f854@default>
References: <75b86334-1d29-4889-b9ae-e2815462d711@default>
	<CACzrW9DWO46818MJJ46yp8cdFt69QNN=-pCK93N-Fru1bmgikA@mail.gmail.com>
	<47f03ddd-1c77-4697-9ce1-f14b9d9547b7@default>
	<CACzrW9DhDBi-kv2Hb6oCao26dpL3ZqHTse59QyXU75Q2mg7RSQ@mail.gmail.com>
	<566B2CFE.3030802@Oracle.com>
	<96b1ddd9-e543-42e5-8597-9b466225f854@default>
Message-ID: <566EDAD9.8090406@Oracle.com>

Hi Ramanand,

Thanks for the cleanup of the test.

On 12/14/2015 3:14 AM, Ramanand Patil wrote:
> RE: <i18n dev> Review request for JDK-8066982: ZonedDateTime.parse() 
> returns wrong ZoneOffset around DST fall transition
>
> Hi Rogerand all,
>
> Please review the updated 
> Webrev:_http://cr.openjdk.java.net/~ntv/ramanand/8066982/webrev.02/_ 
> <http://cr.openjdk.java.net/%7Entv/ramanand/8066982/webrev.02/>
>
DateTimeFormatter.java has an added import that is unused and should be 
removed.

Looks fine.

Thanks,  Roger




> <http://cr.openjdk.java.net/%7Entv/ramanand/8066982/webrev.02/>
>
> Bug:_https://bugs.openjdk.java.net/browse/JDK-8066982_
>
> Roger, please see my commentsabout new tests:
>
> -All my test methodswere earlier generic with main method and hence 
> had/private static/qualifier.I have changed them now to match and to 
> be consistent with the existing tests.Thank you for pointing this.
>
> - I agree with you on this. Particularly when we have tests around DST 
> we can?t avoid timezone data.
>
> - I have defined dataProvider for every method and reduced the test 
> data for cases where zone is not 
> present(/testWithoutZoneWithoutOffset//()/and/testWithOffsetWithoutZone//()/). 
>
>
>         But for the other 2 cases where zone is
>         present(/testWithZoneWithOffset//()/and/testWithZoneWithoutOffset//()/),
>         I feel most of the data cases are necessary and some are
>         required to be on safer side if in future the timezone rule
>         changes. Also, this bug fix mainly affects these cases.
>
>         I have created the dataProvider kepping in mind the below
>         cases for 2 DST zones.
>
>         1. Time before overlap
>
>         2. Time during Overlap
>
>         3. Time after overlap
>
>         4. Valid Offsets for each of these times
>
>         5. Zero Offset for each time
>
>         6. Few Positive and negative invalid offsets for each time
>
> Regards,
>
> Ramanand.
>
> -----Original Message-----
>
> From: Roger Riggs
>
> Sent: Saturday, December 12, 2015 1:37 AM
>
> To:_core-libs-dev at openjdk.java.net_<mailto:core-libs-dev at openjdk.java.net>
>
> Cc:_i18n-dev at openjdk.java.net_<mailto:i18n-dev at openjdk.java.net>
>
> Subject: Re: <i18n dev> Review request for JDK-8066982: 
> ZonedDateTime.parse() returns wrong ZoneOffset around DST fall transition
>
> Hi,
>
> Stephen, can you  confirm that the added text and test in 
> DateTimeFormatter is not a specification change?
>
> Our processes have a bit more to do if it is a spec change and it 
> would limit the backport to JDK 8.
>
> This bug fix will cause an existing TCK/JCK test to fail but that is 
> considered also a bug and is fixed.
>
> test/java/time/tck/java/time/TCKZonedDateTime.java
>
> Ramanand, some comments on the new test:
>
>   - The 'private' qualifier on the tests and data providers is not 
> used in the current tests and
>
>      is not consistently present in the new one.
>
>      Since it has little/no function, the tests would be a bit cleaner 
> without it.
>
>   - Typically, test that have data dependencies (such as the timezone
>
> data) cannot be used for
>
> compatibility to the specification, but the data is stable and it 
> seems unavoidable in this case.
>
>   - Are all of the data cases necessary to validate the specification?
>
> Redundant cases extend the testing time without adding more confidence 
> to the quality.
>
> Thanks, Roger
>
>
> On 12/10/2015 11:00 AM, Stephen Colebourne wrote:
>
> > I believe this is suitable for committing, thanks, other reviews welcome!
>
> > Stephen
>
> >
>
> >
>
> >
>
> > On 10 December 2015 at 15:36, Ramanand Patil 
> <_ramanand.patil at oracle.com_<mailto:ramanand.patil at oracle.com>> wrote:
>
> >> Hi all,
>
> >>
>
> >> Please review the updated webrev:
>
> >>_http://cr.openjdk.java.net/~aefimov/8066982/webrev.01/_<http://cr.openjdk.java.net/%7Eaefimov/8066982/webrev.01/>
>
> >>
>
> >> I have modified the fix and test cases as per inputs given by Stephen. 
> Also, I have added the javadocs changes in this patch which were 
> proposed in the bug.
>
> >>
>
> >> Bug link is:_https://bugs.openjdk.java.net/browse/JDK-8066982_
>
> >>
>
> >>
>
> >> Regards,
>
> >> Ramanand.
>
> >>
>
> >> -----Original Message-----
>
> >> From: Stephen Colebourne [_mailto:scolebourne at joda.org_]
>
> >> Sent: Wednesday, December 09, 2015 4:46 PM
>
> >> To: core-libs-dev
>
> >> Cc: i18n-dev
>
> >> Subject: Re: <i18n dev> Review request for JDK-8066982:
>
> >> ZonedDateTime.parse() returns wrong ZoneOffset around DST fall
>
> >> transition
>
> >>
>
> >> The logic looks fine.
>
> >>
>
> >> In the main code, this part
>
> >>.getLong(INSTANT_SECONDS);
>
> >> can be replaced with
>
> >>.toEpochSecond();
>
> >> which will be slightly faster.
>
> >>
>
> >> In the test case, this part
>
> >>.plus(15, ChronoUnit.MINUTES);
>
> >> can be replaced with
>
> >>.plusMinutes(15)
>
> >>
>
> >> And
>
> >>.with(ChronoField.OFFSET_SECONDS,
>
> >> ZoneOffset.of(offsetSamples[j]).getTotalSeconds())
>
> >> can be replaced with
>
> >>.with(ZoneOffset.of(offsetSamples[j]))
>
> >>
>
> >> In addition to the looping tests, I'd like to see the examples from the 
> bug report as test cases. Those tests would be simple to follow and 
> explain, whereas the looping tests are a little hard to follow.
>
> >>
>
> >> thanks for fixing this
>
> >> Stephen
>
> >>
>
> >>
>
> >>
>
> >> On 9 December 2015 at 07:44, Ramanand Patil 
> <_ramanand.patil at oracle.com_<mailto:ramanand.patil at oracle.com>> wrote:
>
> >>> HI all,
>
> >>>
>
> >>>
>
> >>>
>
> >>> Please review a fix for Bug  - HYPERLINK
>
> >>> "_https://bugs.openjdk.java.net/browse/JDK-8066982_"JDK-8066982
>
> >>>
>
> >>>
>
> >>>
>
> >>> Bug - Parsing a string with ZonedDateTime.parse() that contains zone 
> offset and zone ID "Europe/Berlin" returns a wrong ZonedDateAndTime 
> (different offset). This error starts exactly at the transition time 
> (included) and ends one hour later (excluded).
>
> >>>
>
> >>>
>
> >>>
>
> >>> Webrev 
> -_http://cr.openjdk.java.net/~aefimov/8066982/webrev.00/_<http://cr.openjdk.java.net/%7Eaefimov/8066982/webrev.00/>
>
> >>>
>
> >>>
>
> >>>
>
> >>> One existing test case in TCKZonedDateTime.java is also modified, 
> because - when offset is invalid the local time is changed to make the 
> result valid.
>
> >>>
>
> >>>
>
> >>>
>
> >>>
>
> >>>
>
> >>> Regards,
>
> >>>
>
> >>> Ramanand.
>
>


From ramanand.patil at oracle.com  Mon Dec 14 15:53:41 2015
From: ramanand.patil at oracle.com (Ramanand Patil)
Date: Mon, 14 Dec 2015 07:53:41 -0800 (PST)
Subject: <i18n dev> Review request for JDK-8066982:
 ZonedDateTime.parse() returns wrong ZoneOffset around DST fall transition
In-Reply-To: <566EDAD9.8090406@Oracle.com>
References: <75b86334-1d29-4889-b9ae-e2815462d711@default>
	<CACzrW9DWO46818MJJ46yp8cdFt69QNN=-pCK93N-Fru1bmgikA@mail.gmail.com>
	<47f03ddd-1c77-4697-9ce1-f14b9d9547b7@default>
	<CACzrW9DhDBi-kv2Hb6oCao26dpL3ZqHTse59QyXU75Q2mg7RSQ@mail.gmail.com>
	<566B2CFE.3030802@Oracle.com>
	<96b1ddd9-e543-42e5-8597-9b466225f854@default>
	<566EDAD9.8090406@Oracle.com>
Message-ID: <eb911305-fbe0-4279-943f-15a42d8607b4@default>

Hi Roger,

?

The added import in DateTimeFormatter.java ?is because of the javadocs entry - {@link ChronoLocalDateTime#atZone(ZoneId)}
?
?
Regards,
Ramanand.

?

From: Roger Riggs 
Sent: Monday, December 14, 2015 8:36 PM
To: Ramanand Patil; core-libs-dev at openjdk.java.net
Cc: i18n-dev at openjdk.java.net
Subject: Re: <i18n dev> Review request for JDK-8066982: ZonedDateTime.parse() returns wrong ZoneOffset around DST fall transition

?

Hi Ramanand,

Thanks for the cleanup of the test.

On 12/14/2015 3:14 AM, Ramanand Patil wrote:

Hi Roger and all,

Please review the updated Webrev: http://cr.openjdk.java.net/~ntv/ramanand/8066982/webrev.02/

DateTimeFormatter.java has an added import that is unused and should be removed.

Looks fine.

Thanks,? Roger







Bug: https://bugs.openjdk.java.net/browse/JDK-8066982

Roger, please see my comments about new tests:

- All my test methods were earlier generic with main method and hence had private static qualifier. I have changed them now to match and to be consistent with the existing tests. Thank you for pointing this.

- I agree with you on this. Particularly when we have tests around DST we can?t avoid timezone data.

- I have defined dataProvider for every method and reduced the test data for cases where zone is not present(testWithoutZoneWithoutOffset() and testWithOffsetWithoutZone()). 

But for the other 2 cases where zone is present(testWithZoneWithOffset() and testWithZoneWithoutOffset()), I feel most of the data cases are necessary and some are required to be on safer side if in future the timezone rule changes. Also, this bug fix mainly affects these cases.

I have created the dataProvider kepping in mind the below cases for 2 DST zones.

1. Time before overlap

2. Time during Overlap

3. Time after overlap

4. Valid Offsets for each of these times

5. Zero Offset for each time

6. Few Positive and negative invalid offsets for each time

Regards,

Ramanand.

-----Original Message-----

From: Roger Riggs 

Sent: Saturday, December 12, 2015 1:37 AM

To: HYPERLINK "mailto:core-libs-dev at openjdk.java.net"core-libs-dev at openjdk.java.net

Cc: HYPERLINK "mailto:i18n-dev at openjdk.java.net"i18n-dev at openjdk.java.net

Subject: Re: <i18n dev> Review request for JDK-8066982: ZonedDateTime.parse() returns wrong ZoneOffset around DST fall transition

Hi,

Stephen, can you? confirm that the added text and test in DateTimeFormatter is not a specification change?

Our processes have a bit more to do if it is a spec change and it would limit the backport to JDK 8.

This bug fix will cause an existing TCK/JCK test to fail but that is considered also a bug and is fixed.

???? test/java/time/tck/java/time/TCKZonedDateTime.java

Ramanand, some comments on the new test:

? - The 'private' qualifier on the tests and data providers is not used in the current tests and

???? is not consistently present in the new one.

???? Since it has little/no function, the tests would be a bit cleaner without it.

? - Typically, test that have data dependencies (such as the timezone

data) cannot be used for

???? compatibility to the specification, but the data is stable and it seems unavoidable in this case.

? - Are all of the data cases necessary to validate the specification?

??? Redundant cases extend the testing time without adding more confidence to the quality.

Thanks,? Roger

?

On 12/10/2015 11:00 AM, Stephen Colebourne wrote:

> I believe this is suitable for committing, thanks, other reviews welcome!

> Stephen

>?

>?

>?

> On 10 December 2015 at 15:36, Ramanand Patil <HYPERLINK "mailto:ramanand.patil at oracle.com"ramanand.patil at oracle.com> wrote:

>> Hi all,

>>?

>> Please review the updated webrev: 

>> HYPERLINK "http://cr.openjdk.java.net/%7Eaefimov/8066982/webrev.01/"http://cr.openjdk.java.net/~aefimov/8066982/webrev.01/

>>?

>> I have modified the fix and test cases as per inputs given by Stephen. Also, I have added the javadocs changes in this patch which were proposed in the bug.

>>?

>> Bug link is: https://bugs.openjdk.java.net/browse/JDK-8066982

>>?

>>?

>> Regards,

>> Ramanand.

>>?

>> -----Original Message-----

>> From: Stephen Colebourne [mailto:scolebourne at joda.org]

>> Sent: Wednesday, December 09, 2015 4:46 PM

>> To: core-libs-dev

>> Cc: i18n-dev

>> Subject: Re: <i18n dev> Review request for JDK-8066982: 

>> ZonedDateTime.parse() returns wrong ZoneOffset around DST fall 

>> transition

>>?

>> The logic looks fine.

>>?

>> In the main code, this part

>>??? .getLong(INSTANT_SECONDS);

>> can be replaced with

>>??? .toEpochSecond();

>> which will be slightly faster.

>>?

>> In the test case, this part

>>?? .plus(15, ChronoUnit.MINUTES);

>> can be replaced with

>>?? .plusMinutes(15)

>>?

>> And

>>?? .with(ChronoField.OFFSET_SECONDS,

>> ZoneOffset.of(offsetSamples[j]).getTotalSeconds())

>> can be replaced with

>>?? .with(ZoneOffset.of(offsetSamples[j]))

>>?

>> In addition to the looping tests, I'd like to see the examples from the bug report as test cases. Those tests would be simple to follow and explain, whereas the looping tests are a little hard to follow.

>>?

>> thanks for fixing this

>> Stephen

>>?

>>?

>>?

>> On 9 December 2015 at 07:44, Ramanand Patil <HYPERLINK "mailto:ramanand.patil at oracle.com"ramanand.patil at oracle.com> wrote:

>>> HI all,

>>>?

>>>?

>>>?

>>> Please review a fix for Bug? - HYPERLINK

>>> "https://bugs.openjdk.java.net/browse/JDK-8066982"JDK-8066982

>>>?

>>>?

>>>?

>>> Bug - Parsing a string with ZonedDateTime.parse() that contains zone offset and zone ID "Europe/Berlin" returns a wrong ZonedDateAndTime (different offset). This error starts exactly at the transition time (included) and ends one hour later (excluded).

>>>?

>>>?

>>>?

>>> Webrev - http://cr.openjdk.java.net/~aefimov/8066982/webrev.00/

>>>?

>>>?

>>>?

>>> One existing test case in TCKZonedDateTime.java is also modified, because - when offset is invalid the local time is changed to make the result valid.

>>>?

>>>?

>>>?

>>>?

>>>?

>>> Regards,

>>>?

>>> Ramanand.

?

?

From Roger.Riggs at Oracle.com  Mon Dec 14 16:04:30 2015
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Mon, 14 Dec 2015 11:04:30 -0500
Subject: <i18n dev> Review request for JDK-8066982:
 ZonedDateTime.parse() returns wrong ZoneOffset around DST fall transition
In-Reply-To: <eb911305-fbe0-4279-943f-15a42d8607b4@default>
References: <75b86334-1d29-4889-b9ae-e2815462d711@default>
	<CACzrW9DWO46818MJJ46yp8cdFt69QNN=-pCK93N-Fru1bmgikA@mail.gmail.com>
	<47f03ddd-1c77-4697-9ce1-f14b9d9547b7@default>
	<CACzrW9DhDBi-kv2Hb6oCao26dpL3ZqHTse59QyXU75Q2mg7RSQ@mail.gmail.com>
	<566B2CFE.3030802@Oracle.com>
	<96b1ddd9-e543-42e5-8597-9b466225f854@default>
	<566EDAD9.8090406@Oracle.com>
	<eb911305-fbe0-4279-943f-15a42d8607b4@default>
Message-ID: <566EE88E.8010103@Oracle.com>

Hi,

ok,  (I still think of import is for code, not docs, but it makes the 
{@link}s easier).

Roger


On 12/14/2015 10:53 AM, Ramanand Patil wrote:
> RE: <i18n dev> Review request for JDK-8066982: ZonedDateTime.parse() 
> returns wrong ZoneOffset around DST fall transition
>
> Hi Roger,
>
> The added import in DateTimeFormatter.java  is because of the javadocs 
> entry - {@link ChronoLocalDateTime#atZone(ZoneId)}
> Regards,
> Ramanand.
>
> *From:*Roger Riggs
> *Sent:* Monday, December 14, 2015 8:36 PM
> *To:* Ramanand Patil; core-libs-dev at openjdk.java.net
> *Cc:* i18n-dev at openjdk.java.net
> *Subject:* Re: <i18n dev> Review request for JDK-8066982: 
> ZonedDateTime.parse() returns wrong ZoneOffset around DST fall transition
>
> Hi Ramanand,
>
> Thanks for the cleanup of the test.
>
> On 12/14/2015 3:14 AM, Ramanand Patil wrote:
>
>     Hi Roger and all,
>
>     Please review the updated Webrev:
>     _http://cr.openjdk.java.net/~ntv/ramanand/8066982/webrev.02/
>     <http://cr.openjdk.java.net/%7Entv/ramanand/8066982/webrev.02/>_
>
> DateTimeFormatter.java has an added import that is unused and should 
> be removed.
>
> Looks fine.
>
> Thanks,  Roger
>
>
>
>
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8066982
>
> Roger, please see my comments about new tests:
>
> - All my test methods were earlier generic with main method and hence 
> had///private static/qualifier. I have changed them now to match and 
> to be consistent with the existing tests. Thank you for pointing this.
>
> - I agree with you on this. Particularly when we have tests around DST 
> we can?t avoid timezone data.
>
> - I have defined dataProvider for every method and reduced the test 
> data for cases where zone is not 
> present(/testWithoutZoneWithoutOffset()/and///testWithOffsetWithoutZone()/). 
>
>
> But for the other 2 cases where zone is 
> present(/testWithZoneWithOffset()/and///testWithZoneWithoutOffset()/), 
> I feel most of the data cases are necessary and some are required to 
> be on safer side if in future the timezone rule changes. Also, this 
> bug fix mainly affects these cases.
>
> I have created the dataProvider kepping in mind the below cases for 2 
> DST zones.
>
> 1. Time before overlap
>
> 2. Time during Overlap
>
> 3. Time after overlap
>
> 4. Valid Offsets for each of these times
>
> 5. Zero Offset for each time
>
> 6. Few Positive and negative invalid offsets for each time
>
> Regards,
>
> Ramanand.
>
> -----Original Message-----
>
> From: Roger Riggs
>
> Sent: Saturday, December 12, 2015 1:37 AM
>
> To: core-libs-dev at openjdk.java.net <mailto:core-libs-dev at openjdk.java.net>
>
> Cc: i18n-dev at openjdk.java.net <mailto:i18n-dev at openjdk.java.net>
>
> Subject: Re: <i18n dev> Review request for JDK-8066982: 
> ZonedDateTime.parse() returns wrong ZoneOffset around DST fall transition
>
> Hi,
>
> Stephen, can you  confirm that the added text and test in 
> DateTimeFormatter is not a specification change?
>
> Our processes have a bit more to do if it is a spec change and it 
> would limit the backport to JDK 8.
>
> This bug fix will cause an existing TCK/JCK test to fail but that is 
> considered also a bug and is fixed.
>
> test/java/time/tck/java/time/TCKZonedDateTime.java
>
> Ramanand, some comments on the new test:
>
>   - The 'private' qualifier on the tests and data providers is not 
> used in the current tests and
>
>      is not consistently present in the new one.
>
>      Since it has little/no function, the tests would be a bit cleaner 
> without it.
>
>   - Typically, test that have data dependencies (such as the timezone
>
> data) cannot be used for
>
>      compatibility to the specification, but the data is stable and it 
> seems unavoidable in this case.
>
>   - Are all of the data cases necessary to validate the specification?
>
>     Redundant cases extend the testing time without adding more 
> confidence to the quality.
>
> Thanks,  Roger
>
> On 12/10/2015 11:00 AM, Stephen Colebourne wrote:
>
> > I believe this is suitable for committing, thanks, other reviews welcome!
>
> > Stephen
>
> >
>
> >
>
> >
>
> > On 10 December 2015 at 15:36, Ramanand Patil <ramanand.patil at oracle.com 
> <mailto:ramanand.patil at oracle.com>> wrote:
>
> >> Hi all,
>
> >>
>
> >> Please review the updated webrev:
>
> >> http://cr.openjdk.java.net/~aefimov/8066982/webrev.01/ 
> <http://cr.openjdk.java.net/%7Eaefimov/8066982/webrev.01/>
>
> >>
>
> >> I have modified the fix and test cases as per inputs given by Stephen. Also, I have 
> added the javadocs changes in this patch which were proposed in the bug.
>
> >>
>
> >> Bug link is: _https://bugs.openjdk.java.net/browse/JDK-8066982_
>
> >>
>
> >>
>
> >> Regards,
>
> >> Ramanand.
>
> >>
>
> >> -----Original Message-----
>
> >> From: Stephen Colebourne [_mailto:scolebourne at joda.org_]
>
> >> Sent: Wednesday, December 09, 2015 4:46 PM
>
> >> To: core-libs-dev
>
> >> Cc: i18n-dev
>
> >> Subject: Re: <i18n dev> Review request for JDK-8066982:
>
> >> ZonedDateTime.parse() returns wrong ZoneOffset around DST fall
>
> >> transition
>
> >>
>
> >> The logic looks fine.
>
> >>
>
> >> In the main code, this part
>
> >>.getLong(INSTANT_SECONDS);
>
> >> can be replaced with
>
> >>.toEpochSecond();
>
> >> which will be slightly faster.
>
> >>
>
> >> In the test case, this part
>
> >>   .plus(15, ChronoUnit.MINUTES);
>
> >> can be replaced with
>
> >>.plusMinutes(15)
>
> >>
>
> >> And
>
> >>.with(ChronoField.OFFSET_SECONDS,
>
> >> ZoneOffset.of(offsetSamples[j]).getTotalSeconds())
>
> >> can be replaced with
>
> >>.with(ZoneOffset.of(offsetSamples[j]))
>
> >>
>
> >> In addition to the looping tests, I'd like to see the examples from the bug report 
> as test cases. Those tests would be simple to follow and explain, 
> whereas the looping tests are a little hard to follow.
>
> >>
>
> >> thanks for fixing this
>
> >> Stephen
>
> >>
>
> >>
>
> >>
>
> >> On 9 December 2015 at 07:44, Ramanand Patil <ramanand.patil at oracle.com 
> <mailto:ramanand.patil at oracle.com>> wrote:
>
> >>> HI all,
>
> >>>
>
> >>>
>
> >>>
>
> >>> Please review a fix for Bug  - HYPERLINK
>
> >>> "_https://bugs.openjdk.java.net/browse/JDK-8066982_"JDK-8066982
>
> >>>
>
> >>>
>
> >>>
>
> >>> Bug - Parsing a string with ZonedDateTime.parse() that contains zone offset and 
> zone ID "Europe/Berlin" returns a wrong ZonedDateAndTime (different 
> offset). This error starts exactly at the transition time (included) 
> and ends one hour later (excluded).
>
> >>>
>
> >>>
>
> >>>
>
> >>> Webrev - _http://cr.openjdk.java.net/~aefimov/8066982/webrev.00/ 
> <http://cr.openjdk.java.net/%7Eaefimov/8066982/webrev.00/>_
>
> >>>
>
> >>>
>
> >>>
>
> >>> One existing test case in TCKZonedDateTime.java is also modified, because - when 
> offset is invalid the local time is changed to make the result valid.
>
> >>>
>
> >>>
>
> >>>
>
> >>>
>
> >>>
>
> >>> Regards,
>
> >>>
>
> >>> Ramanand.
>


From naoto.sato at oracle.com  Fri Dec 18 23:33:54 2015
From: naoto.sato at oracle.com (Naoto Sato)
Date: Fri, 18 Dec 2015 15:33:54 -0800
Subject: <i18n dev> [9] RFR: 8134916: LocaleData.cldr for
 sun/text/resources/LocaleDataTest.java seems to contain wrong data
Message-ID: <567497E2.5040605@oracle.com>

Hello,

Please review the fix to the subject bug:

https://bugs.openjdk.java.net/browse/JDK-8134916

The proposed fix is located at:

http://cr.openjdk.java.net/~naoto/8134916/webrev.00/

The gist of the issue was that the test case was unaware of CLDR's 
parent locales lookup chain. Both the test case itself and the test data 
are corrected.

Naoto

From masayoshi.okutsu at oracle.com  Mon Dec 21 07:08:55 2015
From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu)
Date: Mon, 21 Dec 2015 16:08:55 +0900
Subject: <i18n dev> [9] RFR: 8134916: LocaleData.cldr for
 sun/text/resources/LocaleDataTest.java seems to contain wrong data
In-Reply-To: <567497E2.5040605@oracle.com>
References: <567497E2.5040605@oracle.com>
Message-ID: <5677A587.6040507@oracle.com>

Looks good to me.

Masayoshi

On 12/19/2015 8:33 AM, Naoto Sato wrote:
> Hello,
>
> Please review the fix to the subject bug:
>
> https://bugs.openjdk.java.net/browse/JDK-8134916
>
> The proposed fix is located at:
>
> http://cr.openjdk.java.net/~naoto/8134916/webrev.00/
>
> The gist of the issue was that the test case was unaware of CLDR's 
> parent locales lookup chain. Both the test case itself and the test 
> data are corrected.
>
> Naoto