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

[Naoto Sato]

Here is the proposed spec changes:

http://cr.openjdk.java.net/~naoto/8191349/specdiff.00/overview-summary.html

Naoto


On 11/15/17 10:06 AM, Naoto Sato wrote:
> On 11/14/17 4:44 PM, Stephen Colebourne wrote:
>> On 14 November 2017 at 23:58, Naoto Sato <naoto.sato at oracle.com> wrote:
>>> So even with the new suggested method,
>>>
>>> formatter.withZone(locale).withLocalization(locale)
>>> formatter.withLocalization(locale).withZone(locale)
>>>
>>> would produce different formatters. Would it be OK, assuming along 
>>> with some
>>> proper documentation?
>>
>> Thats why I suggested perhaps a different method name is needed, not
>> withXxx() to highlight the larger impact. eg. localizedBy(Locale)
> 
> OK. Will come up with a draft. Essentially what the new method does is 
> what withLocale() does, plus replacing fields specified with Unicode 
> extensions (calendar/timezone/region override)
> 
>>
>>>>    DateTimeFormatterBuilder.toFormatter(Locale, ResolverStyle,
>>>> Chronology) has new logic to override the chronology. But this method
>>>> is used indirectly from ofLocalizedTime() and friends which require
>>>> the output to be ISO chronology. Thus the webrev would break the
>>>> specification of those methods.
>>>
>>> Would you suggest not interpreting extensions in this method? I am now
>>> inclined to just interpret locale extensions in the new suggested 
>>> method for
>>> the java.time package.
>>
>> Fundamentally, the tags you are processing are a problem for the
>> design of java.time formatters. The existing API is structured around
>> a narrow meaning of Locale for text input/output within the formatting
>> API.
>>
>> Changing the behaviour of DateTimeFormatterBuilder.toFormatter(...)
>> methods could have some odd effects for end-user code. Where they are
>> currently just expecting the locale to be set to control text
>> input/output, it would suddenly affect the calendar system and
>> time-zone, which could break code/compatibility in certain cases.
> 
> I've decided to retract changes in 
> DateTimeFormatter/DateTimeFormatterBuilder currently in the webrev, with 
> adding some text noting Unicode extensions are ignored in those methods.
> 
>>
>> I think that its OK to use the unicode tags in places like
>> WeekFields.of() or Chronology.of(). But for formatting, the change in
>> meaning is too great. Adding a single method (name TBD) makes more
>> sense
> Will keep the changes in WeekFields.of()/Chronology.of()
> 
>>
>> There is a case to add ZoneId.ofLocale(Locale) to match
>> Chronology.ofLocale(Locale). However, the expectation would be that it
>> figures out a suitable time-zone for the country/region as well as
>> considering the -u-tz- tag, and I don't think you've got that data
>> available at present (but it would make a good follow on change).
> 
> Yes, we don't yet have that mechanism to derive time zone based on the 
> region. I think that's out of this JEP's scope.
> 
> Naoto