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][1]) 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.


  [1]: https://bugs.openjdk.java.net/browse/JDK-8191501