On Sat, 4 Dec 2021 22:34:50 GMT, Naoto Sato <na...@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
