On 14 November 2017 at 23:58, Naoto Sato <naoto.s...@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) >> 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 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. 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). Stephen
