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

[Naoto Sato]

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