<i18n dev> RFR: 8275721: Name of UTC timezone in a locale changes depending on previous code [v3]

[Naoto Sato]

On Mon, 6 Dec 2021 18:52:51 GMT, Joe Wang <joehw at openjdk.org> wrote:

>> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Use isFixedOffset() instead of useDaylightTime()
>
> src/java.base/share/classes/sun/util/cldr/CLDRTimeZoneNameProviderImpl.java line 31:
> 
>> 29: 
>> 30: import java.text.MessageFormat;
>> 31: import java.time.ZoneId;
> 
> nit, the import is not used?

Right. Removed.

> test/jdk/sun/util/resources/TimeZone/ChineseTimeZoneNameTest.java line 66:
> 
>> 64: 
>> 65:     @Test(dataProvider="locales")
>> 66:     public void test_ChineseTimeZoneNames(Locale testLoc, Locale resourceLoc) {
> 
> Does this test exercise the problem as in the original test? Do we need a test to reproduce the calling sequence as the original test?
> 
> The original issue seems to me was that the names were dependent on the order of calls, due to the name being cached. That is, if utcNameIn("zh-Hant-HK") is called first, subsequent call utcNameIn("zh-MO") would get the cached name from the call (zh-Hant-HK), but if the later is called first, it would not have the problem, that is, the following would return a correct name (協調世界時間):
> utcNameIn("zh-MO"); utcNameIn("zh-Hant-HK"); utcNameIn("zh-MO");

`協調世界時間` is actually coming from `COMPAT` provider, which is wrong. The expected name `世界標準時間` in CLDR is in `zh-Hant` resource bundle which is not available in `COMPAT` provider. Thus, comparing `zh-MO` and `zh-Hant` names effectively asserts that the name is correctly coming from `CLDR` provider. I confirmed that this regression test did fail with the runtime without the proposed fix.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6709