<i18n dev> [15] RFR: 8234347: "Turkey" meta time zone does not generate composed localized names, 8236548: Localized time zone name inconsistency between English and other locales

naoto.sato at oracle.com naoto.sato at oracle.com
Mon Feb 10 22:45:48 UTC 2020


Drafted a CSR:

https://bugs.openjdk.java.net/browse/JDK-8238809

Appreciate the review for this as well.

Naoto

On 2/10/20 8:52 AM, naoto.sato at oracle.com wrote:
> Good point. I will file a CSR for the behavioral changes.
> 
> Naoto
> 
> On 2/7/20 6:00 PM, Joe Wang wrote:
>> Hi Naoto,
>>
>> I see the existing tests were changed, e.g. the abbreviation / short 
>> timezone name, the result of calling getDisplayName. Would you need a 
>> CSR to discuss/document the potential incompatibility?
>>
>> Best,
>> Joe
>>
>> On 2/7/20 1:44 PM, naoto.sato at oracle.com wrote:
>>> Hello,
>>>
>>> Please review the fix to the following issues:
>>>
>>> https://bugs.openjdk.java.net/browse/JDK-8234347
>>> https://bugs.openjdk.java.net/browse/JDK-8236548
>>>
>>> The proposed changeset is located at:
>>>
>>> http://cr.openjdk.java.net/~naoto/8234347.8236548/webrev.00/
>>>
>>> This changeset includes the following changes:
>>>
>>> - English time zone names missing in CLDR source files are no longer 
>>> copied from COMPAT provider at build time. Rather it is synthesized 
>>> at runtime, which has been the way other locales did.
>>>
>>> - Runtime CLDR time zone name provider fallback logic has been 
>>> refined. It now falls back to parent locales per each missing name, 
>>> instead of resource bundle. Also, region fall back is now using 
>>> exemplar city to synthesize the name (e.g., "Turkey" meta zone)
>>>
>>> - Minor fix in DateTimeFormatterBuilder on zone text parsing. It now 
>>> parses zone texts that start with "UTC", yet it is ZoneId.
>>>
>>> Naoto
>>


More information about the i18n-dev mailing list