Summary

java.time.DateTimeFormatter.localizedBy(Locale) method should reflect the default localized values for the specified locale.

Problem

localizedBy(Locale) method was introduced in JDK 10 to support Unicode Extensions in the specified locale (JDK-8191501) so that the generated formatter will have the appropriate Chronology, DecimalStyle, and/or ZoneId. However, the method does not honor the default localized values specified with the locale, such as Arabic-Indic number system for locales in the Arab area. For example, with the current JDK:

jshell> DateTimeFormatter.ofLocalizedDate(FormatStyle.FULL)
    .localizedBy(Locale.forLanguageTag("fa"))
    .format(LocalDate.now())
$3 ==> "جمعه 1 مهٔ 2020"

whereas the exepcted behavior would be:

jshell> DateTimeFormatter.ofLocalizedDate(FormatStyle.FULL)
    .localizedBy(Locale.forLanguageTag("fa"))
    .format(LocalDate.now())
$3 ==> "جمعه ۱ مهٔ ۲۰۲۰"

because the Extended Arabic-Indic is the default numbering system for Farsi locale.

Solution

The localizedBy(Locale) method will instantiate a formatter with the Chronology and/or DecimalStyle values for the specified locale argument, as well as the specified ones with the Unicode Extensions. If the value specified with Unicode Extension and the locale values conflict, Unicode Extension one always takes precedence. Note that ZoneId is not in this CSR's scope, as locale and zone id are not a 1:1 match.

Specification

N/A. This is a behavioral change only.