[10] RFR 8176841: Additional Unicode Language-Tag Extensions

[Naoto Sato]

Thanks, Stephen.

On 11/21/17 1:35 AM, Stephen Colebourne wrote:
> On 21 November 2017 at 01:45, Naoto Sato <naoto.sato at oracle.com> wrote:
>>> 2) `DecimalStyle.ofLocale(Locale)` should use "nu" but does not.
>>
>> Document it in the javadoc.
> 
> Javadoc looks good, but the webrev didn't contain matching code last
> time I looked.

I haven't updated the webrev yet, since it will involve new test cases. 
I wanted to make sure the direction of the change was correct. Will 
update the webrev soon.

> 
>>> 3) `DateTimeFormatter.localizedBy(Locale)` should use "ca" to call
>>> `withChronology`, `tz` to call `withZoneId` and `nu` to call
>>> `withDecimalStyle`. This is a change to the CSR.
>>
>> Besides that "nu" needs to be spec'ed out, isn't calling withXXXX() an
>> implementation note?
> 
> The revised text ends with "Same is true for the "nu" extension.", but
> doesn't mention the case where both "tz" and "rg" are present.

Since there is no ZoneId.ofLocale(rg), a region does not designate a 
time zone (yet). So there would be no conflict between "tz" and "rg" 
extensions.

> 
>>> 7) WeekBasedFieldPrinterParser should use "fw"/"rg", which it already
>>> does via WeekFields.of(Locale)
>>
>> Not sure what this means. Where is the file located?
> 
> WeekBasedFieldPrinterParser is an inner class of DateTimeFormatterBuilder

OK, thanks.

> 
>>> 10) Consider how localizedBy(Locale) operates.
>>
>> IIRC, the localizedBy() is added so that withLocale() would behave as it is
>> now. I think localizedBy() should also have the same effect as withLocale if
>> the specified locale do not contain any calendar/timezone/numberingSystem
>> extensions. Otherwise, say localizedBy(Locale.JAPAN) would be no-operation.
> 
> OK, I agree. localizedBy(locale) is the same as withLocale(locale)
> unless there are "ca", "tz" or "nu", in which case the matching
> element is updated.

Good.

Naoto