Hi,
This would be a useful addition. Some comments:
There is no need for the method overload that takes Locale. The other
similar methods all operate using the locale of the formatter, and
have this Javadoc:
* The locale is determined from the formatter. The formatter
returned directly by
* this method will use the {@link Locale#getDefault() default
FORMAT locale}.
* The locale can be controlled using {@link
DateTimeFormatter#withLocale(Locale) withLocale(Locale)}
* on the result of this method.
And `appendLocalizedPattern` should not take a Locale either. Again ,
it would use the locale of the formatter instance, calculating the
actual pattern on-demand when the formatter is run.
The spec Javadoc doesn't explain what repeating the pattern letter
actually does/means. Is "M" the same as "MMMM"?
thanks
Stephen
On Thu, 20 Jan 2022 at 21:47, Naoto Sato <naoto.s...@oracle.com> wrote:
>
> Hello,
>
> I am proposing a couple of new factory methods in
> java.time.format.DateTimeFormatter that produce flexible localized
> date/time formats, other than the existing pre-defined
> (FULL/LONG/MEDIUM/SHORT) styles. For example, if the user wants a year
> and month only string, such as the title for the calendar, currently
> they would have to use DateTimeFormatter.ofPattern() with explicit
> pattern argument, such as "MMM y". This is problematic because it is
> correct in locales such as US, but not correct in other locales.
>
> So, I propose methods that are parallel to ofPattern(), which take
> pattern template. This is based on the CLDR's skeleton:
> https://www.unicode.org/reports/tr35/tr35-dates.html#availableFormats_appendItems
>
> Detailed design can be found in the draft CSR:
> https://bugs.openjdk.java.net/browse/JDK-8243445
>
> Comments are welcome.
>
> Naoto
>
