Fix Version/s: 15
Compatibility Risk Description:The chronology and number system from the locale may be different from that returned by the existing formatter, the change is from a generic chronology or number system to one that is locale specific.
Interface Kind:Java API
java.time.DateTimeFormatter.localizedBy(Locale) method should reflect the default localized values for the specified locale.
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
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.
localizedBy(Locale) method will instantiate a formatter with the
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.
N/A. This is a behavioral change only.