RFR 8176841: Additional Unicode Language-Tag Extensions
scolebourne at joda.org
Wed Nov 15 00:44:50 UTC 2017
On 14 November 2017 at 23:58, Naoto Sato <naoto.sato at oracle.com> wrote:
> So even with the new suggested method,
> 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)
>> 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
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 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
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).
More information about the core-libs-dev