Updated the CSR (https://bugs.openjdk.java.net/browse/JDK-8243445), by
adding a regular expression for the requested template. This way, it is
less depending on the LDML specification.
Naoto
On 1/21/22 2:39 PM, Naoto Sato wrote:
Thanks, Joe.
Good point. I will elaborate the pattern template part more, less
depending on the LDML spec. Would have been better if we could introduce
our own, such as ofLocalizedPattern(Set<ChronoField> template), but not
exactly suffices the need.
Naoto
On 1/20/22 9:52 PM, Joe Wang wrote:
Hi Naoto,
The javadoc points to LDML, it seems to me though it might be useful
to add more information similar to that for the ofPattern methods,
what's under the "Patterns for Formatting and Parsing" section, so
that for at least the common use cases we could rely on the javadoc
without having to consult the LDML specification. Some comparison with
the ofPattern methods might also be helpful.
Just my 2 cents.
Thanks,
Joe
On 1/20/22 1:46 PM, Naoto Sato 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
