RFR 8158880: java/time/tck/java/time/format/TCKDateTimeFormatterBuilder.java fail with zh_CN locale

[Naoto Sato]

Hi Bhanu, Nadeesh,

As to which locale to use, I suggest using US English (Locale.US), since 
that is the one in java.base module. Using Locale.UK could cause 
unexpected fallback to Locale.US if jdk.localedata module is not available.

Naoto

On 11/11/16 12:39 AM, nadeesh tv wrote:
> Hi Bhanu,
>
>
> I think adding Locale to the formatter will be better
>
> For eg:
>
> DateTimeFormatter f =
> builder.parseLenient().appendValue(HOUR_OF_DAY).appendValue(MINUTE_OF_HOUR,
> 2).appendLiteral('9').toFormatter(Locale.UK);
>
> Since other test cases use Locale.UK may be here also you can use UK
> instead of locale.US.
>
> Thanks and Regards,
> Nadeesh
>
>
> On 11/11/2016 10:57 AM, Bhanu Gopularam wrote:
>> Hi Roger,
>>
>>
>> Thanks for the review. I have updated the test to set default locale
>> (and restore it) in only those methods which were causing problem in
>> non English locales.
>>
>>
>> Please review the updated webrev below:
>>
>> Webrev: http://cr.openjdk.java.net/~bgopularam/JDK-8158880/webrev.01/
>>
>>
>> Thanks,
>>
>> Bhanu
>>
>>
>> From: Roger Riggs
>> Sent: Tuesday, June 21, 2016 8:36 PM
>> To: Bhanu Gopularam; core-libs-dev at openjdk.java.net
>> Cc: Stephen Colebourne
>> Subject: Re: RFR 8158880:
>> java/time/tck/java/time/format/TCKDateTimeFormatterBuilder.java fail
>> with zh_CN locale
>>
>>
>> Hi Bhanu,
>>
>> It can be problematic to change the default Locale for the entire
>> process, especially
>> since many tests are run in the same process.  It would be preferable
>> to set the locale
>> in the DateTimeFormatter builder instead of changing the process wide
>> Locale.
>>
>> Please identify the specific test case to apply the fix only where
>> needed.
>>
>> Is it only
>> tck.java.time.format.TCKDateTimeFormatterBuilder.test_appendZoneText_parseGenericTimeZonePatterns
>>
>> where the failure is seen?
>>
>> This would be an issue testing any pattern letter with locale
>> dependent behavior.
>> The locale should be set explicitly in the test.
>>
>> BTW,  There is a predefined Locale.US that can be used, no need to
>> construct a new Locale.
>>
>> Roger
>>
>>
>>
>> On 6/21/2016 6:31 AM, Bhanu Gopularam wrote:
>>
>> Hi all,
>>   May I request you to review fix for following issue
>> Bug id: https://bugs.openjdk.java.net/browse/JDK-8158880
>>   Solution: To avoid test failure in non english locales, set the
>> default locale while initial test setup
>>   Webrev: http://cr.openjdk.java.net/~bgopularam/JDK-8158880/webrev.00/
>>   Thanks,
>> Bhanu
>>
>>
>