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

[Joe Wang]

On Sat, 4 Dec 2021 22:34:50 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Fixing time zone name provider for CLDR. In some cases, COMPAT's `UTC` display names were incorrectly substituted for CLDR. The reason it worked fine after `zh-Hant-HK` was that by loading names for `zh-Hant-HK`, the names for `zh-Hant` were cached and hit for the following `zh-MO` name retrieval.
>
> 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?

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");

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

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