Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-8244246

localizedBy() should override localized values with default values

    Details

    • Type: CSR
    • Status: Closed
    • Priority: P4
    • Resolution: Approved
    • Fix Version/s: 15
    • Component/s: core-libs
    • Labels:
      None
    • Subcomponent:
    • Compatibility Kind:
      behavioral
    • Compatibility Risk:
      low
    • 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
    • Scope:
      SE

      Description

      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.

        Attachments

          Issue Links

            Activity

              People

              • Assignee:
                naoto Naoto Sato
                Reporter:
                naoto Naoto Sato
                Reviewed By:
                Roger Riggs
              • Votes:
                0 Vote for this issue
                Watchers:
                1 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: