On Mon, 6 Dec 2021 18:52:51 GMT, Joe Wang <jo...@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
