From naoto.sato at oracle.com  Mon Jan  4 19:10:52 2016
From: naoto.sato at oracle.com (Naoto Sato)
Date: Mon, 4 Jan 2016 11:10:52 -0800
Subject: <i18n dev> [9] RFR: Host Locale Provider Adapter fixes on Windows
Message-ID: <568AC3BC.2080206@oracle.com>

Hello,

I fixed several bugs in Windows' host locale provider adapter:

8039301: [ja] Host Locale Provider uses non-translated Calendar field names
8039969: Old Korean Calendar conflicts with Host Locale
8049835: [ar/HOST adapter] Hijri calendar era is used but date number 
follows gregorian
8054010: [HOST provider, not gregory] Return NULL when calling 
Calendar.getDisplayNames for Calendar.ERA
8054482: [HOST provider] only return standalone-style month display name
8055258: [HOST provider] Short era display name is not returned

The gist of those issues was due to the fact that Windows host adapter 
did not implement CalendarNameProvider. The proposed changes are located at:

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

Naoto

From masayoshi.okutsu at oracle.com  Tue Jan  5 04:36:15 2016
From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu)
Date: Tue, 5 Jan 2016 13:36:15 +0900
Subject: <i18n dev> [9] RFR: Host Locale Provider Adapter fixes on
	Windows
In-Reply-To: <568AC3BC.2080206@oracle.com>
References: <568AC3BC.2080206@oracle.com>
Message-ID: <568B483F.4010402@oracle.com>

The copyright year should be 2016 now. Otherwise, the fixes look OK to me.

Masayoshi

On 1/5/2016 4:10 AM, Naoto Sato wrote:
> Hello,
>
> I fixed several bugs in Windows' host locale provider adapter:
>
> 8039301: [ja] Host Locale Provider uses non-translated Calendar field 
> names
> 8039969: Old Korean Calendar conflicts with Host Locale
> 8049835: [ar/HOST adapter] Hijri calendar era is used but date number 
> follows gregorian
> 8054010: [HOST provider, not gregory] Return NULL when calling 
> Calendar.getDisplayNames for Calendar.ERA
> 8054482: [HOST provider] only return standalone-style month display name
> 8055258: [HOST provider] Short era display name is not returned
>
> The gist of those issues was due to the fact that Windows host adapter 
> did not implement CalendarNameProvider. The proposed changes are 
> located at:
>
> http://cr.openjdk.java.net/~naoto/8039301.8039969.8049835.8054010.8054482.8055258/webrev.00/ 
>
>
> Naoto


From naoto.sato at oracle.com  Tue Jan  5 17:44:05 2016
From: naoto.sato at oracle.com (Naoto Sato)
Date: Tue, 5 Jan 2016 09:44:05 -0800
Subject: <i18n dev> [9] RFR: Host Locale Provider Adapter fixes on
	Windows
In-Reply-To: <568B483F.4010402@oracle.com>
References: <568AC3BC.2080206@oracle.com> <568B483F.4010402@oracle.com>
Message-ID: <568C00E5.7000900@oracle.com>

Thanks. Will fix the copyright year before the push.

Naoto

On 1/4/16 8:36 PM, Masayoshi Okutsu wrote:
> The copyright year should be 2016 now. Otherwise, the fixes look OK to me.
>
> Masayoshi
>
> On 1/5/2016 4:10 AM, Naoto Sato wrote:
>> Hello,
>>
>> I fixed several bugs in Windows' host locale provider adapter:
>>
>> 8039301: [ja] Host Locale Provider uses non-translated Calendar field
>> names
>> 8039969: Old Korean Calendar conflicts with Host Locale
>> 8049835: [ar/HOST adapter] Hijri calendar era is used but date number
>> follows gregorian
>> 8054010: [HOST provider, not gregory] Return NULL when calling
>> Calendar.getDisplayNames for Calendar.ERA
>> 8054482: [HOST provider] only return standalone-style month display name
>> 8055258: [HOST provider] Short era display name is not returned
>>
>> The gist of those issues was due to the fact that Windows host adapter
>> did not implement CalendarNameProvider. The proposed changes are
>> located at:
>>
>> http://cr.openjdk.java.net/~naoto/8039301.8039969.8049835.8054010.8054482.8055258/webrev.00/
>>
>>
>> Naoto
>

From ramanand.patil at oracle.com  Thu Jan 14 12:21:51 2016
From: ramanand.patil at oracle.com (Ramanand Patil)
Date: Thu, 14 Jan 2016 04:21:51 -0800 (PST)
Subject: <i18n dev> RFR: JDK-8144988: Unexpected timezone returned after
 parsing a date
Message-ID: <50c6e11a-b026-4e8e-aa7e-e9f7498fc805@default>

Hi all,
 
Please review the fix for bug: https://bugs.openjdk.java.net/browse/JDK-8144988
 
Webrev: http://cr.openjdk.java.net/~rpatil/8141243/webrev.00
 
This is basically a backport of JDK9 bug: https://bugs.openjdk.java.net/browse/JDK-8141243
 
JDK9 changeset(for reference): http://hg.openjdk.java.net/jdk9/dev/jdk/rev/a1aa2671f281
 
Reason for the review request is because of: 
i)     Changes present in ResourceBundleGenerator.java file.
ii)   The patch from JDK9 does not automatically apply as is after using unshuffle_patch script. Few paths are adjusted as per the jdk8.
 
Since CLDR became the default locale data in JDK9 leading incompatible behavior with prior releases, the relevant code in ResourceBundleGenerator is also backported in this patch.
Even though JDK8 has CLDR locale provider disabled by default, the code change is done to be on safer side for cases where CLDR may be supporting "UTC" ID in the future.
 
 
Regards,
Ramanand.

From naoto.sato at oracle.com  Thu Jan 14 18:13:34 2016
From: naoto.sato at oracle.com (Naoto Sato)
Date: Thu, 14 Jan 2016 10:13:34 -0800
Subject: <i18n dev> RFR: JDK-8144988: Unexpected timezone returned after
 parsing a date
In-Reply-To: <50c6e11a-b026-4e8e-aa7e-e9f7498fc805@default>
References: <50c6e11a-b026-4e8e-aa7e-e9f7498fc805@default>
Message-ID: <5697E54E.7030605@oracle.com>

Looks good to me.

Naoto

On 1/14/16 4:21 AM, Ramanand Patil wrote:
> Hi all,
>
> Please review the fix for bug: https://bugs.openjdk.java.net/browse/JDK-8144988
>
> Webrev: http://cr.openjdk.java.net/~rpatil/8141243/webrev.00
>
> This is basically a backport of JDK9 bug: https://bugs.openjdk.java.net/browse/JDK-8141243
>
> JDK9 changeset(for reference): http://hg.openjdk.java.net/jdk9/dev/jdk/rev/a1aa2671f281
>
> Reason for the review request is because of:
> i)     Changes present in ResourceBundleGenerator.java file.
> ii)   The patch from JDK9 does not automatically apply as is after using unshuffle_patch script. Few paths are adjusted as per the jdk8.
>
> Since CLDR became the default locale data in JDK9 leading incompatible behavior with prior releases, the relevant code in ResourceBundleGenerator is also backported in this patch.
> Even though JDK8 has CLDR locale provider disabled by default, the code change is done to be on safer side for cases where CLDR may be supporting "UTC" ID in the future.
>
>
> Regards,
> Ramanand.
>

From masayoshi.okutsu at oracle.com  Fri Jan 15 02:47:41 2016
From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu)
Date: Fri, 15 Jan 2016 11:47:41 +0900
Subject: <i18n dev> RFR: JDK-8144988: Unexpected timezone returned after
 parsing a date
In-Reply-To: <50c6e11a-b026-4e8e-aa7e-e9f7498fc805@default>
References: <50c6e11a-b026-4e8e-aa7e-e9f7498fc805@default>
Message-ID: <56985DCD.4070706@oracle.com>

Hi Ramanand,

test/java/text/Format/DateFormat/Bug8141243.java:

   28  * @run main Bug8141243
   29  * @run main/othervm -Djava.locale.providers=COMPAT Bug8141243

"COMPAT" is a new name of "JRE" in JDK 9. It's not supported in 8u. I 
think COMPAT is slightly ignored and that it becomes the same thing as 
line 28. Line 29 should be removed.

Otherwise, the fix looks OK to me.

Masayoshi

On 1/14/2016 9:21 PM, Ramanand Patil wrote:
> Hi all,
>   
> Please review the fix for bug: https://bugs.openjdk.java.net/browse/JDK-8144988
>   
> Webrev: http://cr.openjdk.java.net/~rpatil/8141243/webrev.00
>   
> This is basically a backport of JDK9 bug: https://bugs.openjdk.java.net/browse/JDK-8141243
>   
> JDK9 changeset(for reference): http://hg.openjdk.java.net/jdk9/dev/jdk/rev/a1aa2671f281
>   
> Reason for the review request is because of:
> i)     Changes present in ResourceBundleGenerator.java file.
> ii)   The patch from JDK9 does not automatically apply as is after using unshuffle_patch script. Few paths are adjusted as per the jdk8.
>   
> Since CLDR became the default locale data in JDK9 leading incompatible behavior with prior releases, the relevant code in ResourceBundleGenerator is also backported in this patch.
> Even though JDK8 has CLDR locale provider disabled by default, the code change is done to be on safer side for cases where CLDR may be supporting "UTC" ID in the future.
>   
>   
> Regards,
> Ramanand.


From yuka.kamiya at oracle.com  Fri Jan 15 04:18:07 2016
From: yuka.kamiya at oracle.com (Yuka Kamiya)
Date: Fri, 15 Jan 2016 13:18:07 +0900
Subject: <i18n dev> RFR: JDK-8026766: Add toString() to
	j.u.Locale.LanguageRange.
Message-ID: <569872FF.9010404@oracle.com>

Hi,

Please review this simple fix for JDK-8026766: Add toString() to
j.u.Locale.LanguageRange.
https://bugs.openjdk.java.net/browse/JDK-8026766

http://cr.openjdk.java.net/~peytoia/8026766/webrev.00/

Of course, this is an approved API addition.

Thanks,
--
Yuka

From masayoshi.okutsu at oracle.com  Fri Jan 15 05:19:26 2016
From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu)
Date: Fri, 15 Jan 2016 14:19:26 +0900
Subject: <i18n dev> RFR: JDK-8026766: Add toString() to
 j.u.Locale.LanguageRange.
In-Reply-To: <569872FF.9010404@oracle.com>
References: <569872FF.9010404@oracle.com>
Message-ID: <5698815E.8070707@oracle.com>

Looks good to me.

Masayoshi

On 1/15/2016 1:18 PM, Yuka Kamiya wrote:
> Hi,
>
> Please review this simple fix for JDK-8026766: Add toString() to
> j.u.Locale.LanguageRange.
> https://bugs.openjdk.java.net/browse/JDK-8026766
>
> http://cr.openjdk.java.net/~peytoia/8026766/webrev.00/
>
> Of course, this is an approved API addition.
>
> Thanks,
> --
> Yuka


From ramanand.patil at oracle.com  Fri Jan 15 15:31:56 2016
From: ramanand.patil at oracle.com (Ramanand Patil)
Date: Fri, 15 Jan 2016 07:31:56 -0800 (PST)
Subject: <i18n dev> RFR: JDK-8144988: Unexpected timezone returned after
 parsing a date
In-Reply-To: <56985DCD.4070706@oracle.com>
References: <50c6e11a-b026-4e8e-aa7e-e9f7498fc805@default>
	<56985DCD.4070706@oracle.com>
Message-ID: <144a4088-0d5e-4c7c-b249-eb62198f0a01@default>

Hi Masayoshi,

Thank you for pointing that out. I have removed line 29 from the test.

Please review the updated Webrev: http://cr.openjdk.java.net/~rpatil/8141243/webrev.01/


Regards,
Ramanand.

-----Original Message-----
From: Masayoshi Okutsu 
Sent: Friday, January 15, 2016 8:18 AM
To: Ramanand Patil; i18n-dev at openjdk.java.net
Cc: core-libs-dev at openjdk.java.net
Subject: Re: <i18n dev>RFR: JDK-8144988: Unexpected timezone returned after parsing a date

Hi Ramanand,

test/java/text/Format/DateFormat/Bug8141243.java:

   28  * @run main Bug8141243
   29  * @run main/othervm -Djava.locale.providers=COMPAT Bug8141243

"COMPAT" is a new name of "JRE" in JDK 9. It's not supported in 8u. I think COMPAT is slightly ignored and that it becomes the same thing as line 28. Line 29 should be removed.

Otherwise, the fix looks OK to me.

Masayoshi

On 1/14/2016 9:21 PM, Ramanand Patil wrote:
> Hi all,
>   
> Please review the fix for bug: 
> https://bugs.openjdk.java.net/browse/JDK-8144988
>   
> Webrev: http://cr.openjdk.java.net/~rpatil/8141243/webrev.00
>   
> This is basically a backport of JDK9 bug: 
> https://bugs.openjdk.java.net/browse/JDK-8141243
>   
> JDK9 changeset(for reference): 
> http://hg.openjdk.java.net/jdk9/dev/jdk/rev/a1aa2671f281
>   
> Reason for the review request is because of:
> i)     Changes present in ResourceBundleGenerator.java file.
> ii)   The patch from JDK9 does not automatically apply as is after using unshuffle_patch script. Few paths are adjusted as per the jdk8.
>   
> Since CLDR became the default locale data in JDK9 leading incompatible behavior with prior releases, the relevant code in ResourceBundleGenerator is also backported in this patch.
> Even though JDK8 has CLDR locale provider disabled by default, the code change is done to be on safer side for cases where CLDR may be supporting "UTC" ID in the future.
>   
>   
> Regards,
> Ramanand.


From masayoshi.okutsu at oracle.com  Mon Jan 18 06:47:36 2016
From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu)
Date: Mon, 18 Jan 2016 15:47:36 +0900
Subject: <i18n dev> RFR: JDK-8144988: Unexpected timezone returned after
 parsing a date
In-Reply-To: <144a4088-0d5e-4c7c-b249-eb62198f0a01@default>
References: <50c6e11a-b026-4e8e-aa7e-e9f7498fc805@default>
	<56985DCD.4070706@oracle.com>
	<144a4088-0d5e-4c7c-b249-eb62198f0a01@default>
Message-ID: <569C8A88.1070907@oracle.com>

Looks good to me.

Masayoshi

On 1/16/2016 12:31 AM, Ramanand Patil wrote:
> Hi Masayoshi,
>
> Thank you for pointing that out. I have removed line 29 from the test.
>
> Please review the updated Webrev: http://cr.openjdk.java.net/~rpatil/8141243/webrev.01/
>
>
> Regards,
> Ramanand.
>
> -----Original Message-----
> From: Masayoshi Okutsu
> Sent: Friday, January 15, 2016 8:18 AM
> To: Ramanand Patil; i18n-dev at openjdk.java.net
> Cc: core-libs-dev at openjdk.java.net
> Subject: Re: <i18n dev>RFR: JDK-8144988: Unexpected timezone returned after parsing a date
>
> Hi Ramanand,
>
> test/java/text/Format/DateFormat/Bug8141243.java:
>
>     28  * @run main Bug8141243
>     29  * @run main/othervm -Djava.locale.providers=COMPAT Bug8141243
>
> "COMPAT" is a new name of "JRE" in JDK 9. It's not supported in 8u. I think COMPAT is slightly ignored and that it becomes the same thing as line 28. Line 29 should be removed.
>
> Otherwise, the fix looks OK to me.
>
> Masayoshi
>
> On 1/14/2016 9:21 PM, Ramanand Patil wrote:
>> Hi all,
>>    
>> Please review the fix for bug:
>> https://bugs.openjdk.java.net/browse/JDK-8144988
>>    
>> Webrev: http://cr.openjdk.java.net/~rpatil/8141243/webrev.00
>>    
>> This is basically a backport of JDK9 bug:
>> https://bugs.openjdk.java.net/browse/JDK-8141243
>>    
>> JDK9 changeset(for reference):
>> http://hg.openjdk.java.net/jdk9/dev/jdk/rev/a1aa2671f281
>>    
>> Reason for the review request is because of:
>> i)     Changes present in ResourceBundleGenerator.java file.
>> ii)   The patch from JDK9 does not automatically apply as is after using unshuffle_patch script. Few paths are adjusted as per the jdk8.
>>    
>> Since CLDR became the default locale data in JDK9 leading incompatible behavior with prior releases, the relevant code in ResourceBundleGenerator is also backported in this patch.
>> Even though JDK8 has CLDR locale provider disabled by default, the code change is done to be on safer side for cases where CLDR may be supporting "UTC" ID in the future.
>>    
>>    
>> Regards,
>> Ramanand.


From ramanand.patil at oracle.com  Mon Jan 25 07:35:13 2016
From: ramanand.patil at oracle.com (Ramanand Patil)
Date: Sun, 24 Jan 2016 23:35:13 -0800 (PST)
Subject: <i18n dev> RFR: JDK-8147912: test "parseWithZoneWithoutOffset" of
 java/time/tck/java/time/format/TCKDTFParsedInstant.java fail on de_DE
 locale
In-Reply-To: <50c6e11a-b026-4e8e-aa7e-e9f7498fc805@default>
References: <50c6e11a-b026-4e8e-aa7e-e9f7498fc805@default>
Message-ID: <575e40e1-9041-424a-8057-f8c289e032ae@default>

Hi all,
Please review the trivial test bug fix for: https://bugs.openjdk.java.net/browse/JDK-8147912
Bug Description: Since the test case "parseWithZoneWithoutOffset" is using hard code as input data it will fail on some non-English locales (de_DE locale).
Webrev: http://cr.openjdk.java.net/~rpatil/8147912/webrev.00
Fix: Even though hardcoded data is not preferred in compatibility test cases, this case was exception. English is provided as the default locale data for DateTimeFormatter in this testcase.
 
Regards,
Ramanand.

From ramanand.patil at oracle.com  Wed Jan 27 04:51:14 2016
From: ramanand.patil at oracle.com (Ramanand Patil)
Date: Tue, 26 Jan 2016 20:51:14 -0800 (PST)
Subject: <i18n dev> RFR: JDK-8147912: test "parseWithZoneWithoutOffset"
 of java/time/tck/java/time/format/TCKDTFParsedInstant.java fail on de_DE
 locale
In-Reply-To: <575e40e1-9041-424a-8057-f8c289e032ae@default>
References: <50c6e11a-b026-4e8e-aa7e-e9f7498fc805@default>
	<575e40e1-9041-424a-8057-f8c289e032ae@default>
Message-ID: <c73e9b2c-f735-4a49-9431-7727d9617424@default>

Hi all,

 

Please help me in reviewing this test fix.

 

Regards,

Ramanand.

From: Ramanand Patil 
Sent: Monday, January 25, 2016 1:05 PM
To: i18n-dev at openjdk.java.net
Cc: core-libs-dev at openjdk.java.net
Subject: <i18n dev>RFR: JDK-8147912: test "parseWithZoneWithoutOffset" of java/time/tck/java/time/format/TCKDTFParsedInstant.java fail on de_DE locale

 

Hi all,
 
Please review the trivial test bug fix for: https://bugs.openjdk.java.net/browse/JDK-8147912
 
Bug Description: Since the test case "parseWithZoneWithoutOffset" is using hard code as input data it will fail on some non-English locales (de_DE locale).
 
Webrev: http://cr.openjdk.java.net/~rpatil/8147912/webrev.00
 
Fix: Even though hardcoded data is not preferred in compatibility test cases, this case was exception. English is provided as the default locale data for DateTimeFormatter in this testcase.
 
Regards,
Ramanand.

From masayoshi.okutsu at oracle.com  Wed Jan 27 05:53:13 2016
From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu)
Date: Wed, 27 Jan 2016 14:53:13 +0900
Subject: <i18n dev> RFR: JDK-8147912: test "parseWithZoneWithoutOffset"
 of java/time/tck/java/time/format/TCKDTFParsedInstant.java fail on de_DE
 locale
In-Reply-To: <c73e9b2c-f735-4a49-9431-7727d9617424@default>
References: <50c6e11a-b026-4e8e-aa7e-e9f7498fc805@default>
	<575e40e1-9041-424a-8057-f8c289e032ae@default>
	<c73e9b2c-f735-4a49-9431-7727d9617424@default>
Message-ID: <56A85B49.4040704@oracle.com>

Looks OK to me. But I'd like some java.time people to review this change 
to see if the intention of this test is to run only in English.

Thanks,
Masayoshi

On 1/27/2016 1:51 PM, Ramanand Patil wrote:
> Hi all,
>
>   
>
> Please help me in reviewing this test fix.
>
>   
>
> Regards,
>
> Ramanand.
>
> From: Ramanand Patil
> Sent: Monday, January 25, 2016 1:05 PM
> To: i18n-dev at openjdk.java.net
> Cc: core-libs-dev at openjdk.java.net
> Subject: <i18n dev>RFR: JDK-8147912: test "parseWithZoneWithoutOffset" of java/time/tck/java/time/format/TCKDTFParsedInstant.java fail on de_DE locale
>
>   
>
> Hi all,
>   
> Please review the trivial test bug fix for: https://bugs.openjdk.java.net/browse/JDK-8147912
>   
> Bug Description: Since the test case "parseWithZoneWithoutOffset" is using hard code as input data it will fail on some non-English locales (de_DE locale).
>   
> Webrev: http://cr.openjdk.java.net/~rpatil/8147912/webrev.00
>   
> Fix: Even though hardcoded data is not preferred in compatibility test cases, this case was exception. English is provided as the default locale data for DateTimeFormatter in this testcase.
>   
> Regards,
> Ramanand.


From ramanand.patil at oracle.com  Wed Jan 27 06:33:42 2016
From: ramanand.patil at oracle.com (Ramanand Patil)
Date: Tue, 26 Jan 2016 22:33:42 -0800 (PST)
Subject: <i18n dev> RFR: JDK-8147912: test "parseWithZoneWithoutOffset"
 of java/time/tck/java/time/format/TCKDTFParsedInstant.java fail on de_DE
 locale
In-Reply-To: <56A85B49.4040704@oracle.com>
References: <50c6e11a-b026-4e8e-aa7e-e9f7498fc805@default>
	<575e40e1-9041-424a-8057-f8c289e032ae@default>
	<c73e9b2c-f735-4a49-9431-7727d9617424@default>
	<56A85B49.4040704@oracle.com>
Message-ID: <bc4f2e4b-f580-429a-b681-8e6aba73e717@default>

Hi Masayoshi,

 

Thank you for review. This test was contributed by me for bug HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8066982"JDK-8066982.

Running this only in English should be Ok as per me, since this was added just to test one of the parsing scenario when Zone information is available without Offset.

Anyway, I will wait for java.time people to review this change.

 

Regards,

Ramanand.

 

-----Original Message-----
From: Masayoshi Okutsu 
Sent: Wednesday, January 27, 2016 11:23 AM
To: Ramanand Patil; i18n-dev at openjdk.java.net; core-libs-dev at openjdk.java.net
Subject: Re: <i18n dev>RFR: JDK-8147912: test "parseWithZoneWithoutOffset" of java/time/tck/java/time/format/TCKDTFParsedInstant.java fail on de_DE locale

 

Looks OK to me. But I'd like some java.time people to review this change to see if the intention of this test is to run only in English.

 

Thanks,

Masayoshi

 

On 1/27/2016 1:51 PM, Ramanand Patil wrote:

> Hi all,

> 

>   

> 

> Please help me in reviewing this test fix.

> 

>   

> 

> Regards,

> 

> Ramanand.

> 

> From: Ramanand Patil

> Sent: Monday, January 25, 2016 1:05 PM

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

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

> Subject: <i18n dev>RFR: JDK-8147912: test "parseWithZoneWithoutOffset" 

> of java/time/tck/java/time/format/TCKDTFParsedInstant.java fail on 

> de_DE locale

> 

>   

> 

> Hi all,

>   

> Please review the trivial test bug fix for: 

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

>   

> Bug Description: Since the test case "parseWithZoneWithoutOffset" is using hard code as input data it will fail on some non-English locales (de_DE locale).

>   

> Webrev: http://cr.openjdk.java.net/~rpatil/8147912/webrev.00

>   

> Fix: Even though hardcoded data is not preferred in compatibility test cases, this case was exception. English is provided as the default locale data for DateTimeFormatter in this testcase.

>   

> Regards,

> Ramanand.

 

 

From scolebourne at joda.org  Wed Jan 27 10:26:54 2016
From: scolebourne at joda.org (Stephen Colebourne)
Date: Wed, 27 Jan 2016 10:26:54 +0000
Subject: <i18n dev> RFR: JDK-8147912: test "parseWithZoneWithoutOffset"
 of java/time/tck/java/time/format/TCKDTFParsedInstant.java fail on de_DE
 locale
In-Reply-To: <56A85B49.4040704@oracle.com>
References: <50c6e11a-b026-4e8e-aa7e-e9f7498fc805@default>
	<575e40e1-9041-424a-8057-f8c289e032ae@default>
	<c73e9b2c-f735-4a49-9431-7727d9617424@default>
	<56A85B49.4040704@oracle.com>
Message-ID: <CACzrW9AtkvmFnyqunWVasvnfTgHAYt_Ds6ue8KsgvyDHOw4-Ww@mail.gmail.com>

>From the name of the test and looking at the code, running in English only
is fine.
Stephen

On 27 January 2016 at 05:53, Masayoshi Okutsu <masayoshi.okutsu at oracle.com>
wrote:

> Looks OK to me. But I'd like some java.time people to review this change
> to see if the intention of this test is to run only in English.
>
> Thanks,
> Masayoshi
>
>
> On 1/27/2016 1:51 PM, Ramanand Patil wrote:
>
>> Hi all,
>>
>>
>> Please help me in reviewing this test fix.
>>
>>
>> Regards,
>>
>> Ramanand.
>>
>> From: Ramanand Patil
>> Sent: Monday, January 25, 2016 1:05 PM
>> To: i18n-dev at openjdk.java.net
>> Cc: core-libs-dev at openjdk.java.net
>> Subject: <i18n dev>RFR: JDK-8147912: test "parseWithZoneWithoutOffset" of
>> java/time/tck/java/time/format/TCKDTFParsedInstant.java fail on de_DE locale
>>
>>
>> Hi all,
>>   Please review the trivial test bug fix for:
>> https://bugs.openjdk.java.net/browse/JDK-8147912
>>   Bug Description: Since the test case "parseWithZoneWithoutOffset" is
>> using hard code as input data it will fail on some non-English locales
>> (de_DE locale).
>>   Webrev: http://cr.openjdk.java.net/~rpatil/8147912/webrev.00
>>   Fix: Even though hardcoded data is not preferred in compatibility test
>> cases, this case was exception. English is provided as the default locale
>> data for DateTimeFormatter in this testcase.
>>   Regards,
>> Ramanand.
>>
>
>