On Thu, 5 Feb 2026 22:32:16 GMT, Justin Lu <[email protected]> wrote: >> Fixing the Windows default time zones returned from `TimeZone.getDefault()` >> for some regions. On Windows, it uses their own regions for time zones that >> aren't 1-1 match to IANA's TZ database. Thus a mapping table is created as >> `conf/tzmappings` on Windows Java runtime. It is derived from CLDR's >> `windowsZones.xml` but it uses the obsolete IANA ids for their compatibility >> reasons. The fix is to replace the CLDR's old ids to the latest IANA ids for >> those regions. >> Since it is hard to provide an automated test, as it involves the >> modification of the Windows' default time zone, regression test is not >> provided. Instead the fix is manually confirmed using the JIRA issue's >> example. Since this is a change in behavior, I will file a corresponding >> CSR/RN. >> >> Here is the diff of the generated `conf/tzmappings` for reference: >> >> @@ -13,7 +13,7 @@ >> Arabian Standard Time:ZZ:Etc/GMT-4: >> Arabian Standard Time:001:Asia/Dubai: >> Arabic Standard Time:001:Asia/Baghdad: >> -Argentina Standard Time:001:America/Buenos_Aires: >> +Argentina Standard Time:001:America/Argentina/Buenos_Aires: >> Astrakhan Standard Time:001:Europe/Astrakhan: >> Atlantic Standard Time:BM:Atlantic/Bermuda: >> Atlantic Standard Time:GL:America/Thule: >> @@ -58,7 +58,7 @@ >> Central European Standard Time:MK:Europe/Skopje: >> Central European Standard Time:001:Europe/Warsaw: >> Central Pacific Standard Time:AQ:Antarctica/Casey: >> -Central Pacific Standard Time:FM:Pacific/Ponape: >> +Central Pacific Standard Time:FM:Pacific/Pohnpei: >> Central Pacific Standard Time:NC:Pacific/Noumea: >> Central Pacific Standard Time:VU:Pacific/Efate: >> Central Pacific Standard Time:ZZ:Etc/GMT-11: >> @@ -75,7 +75,7 @@ >> Dateline Standard Time:001:Etc/GMT+12: >> E. Africa Standard Time:AQ:Antarctica/Syowa: >> E. Africa Standard Time:DJ:Africa/Djibouti: >> -E. Africa Standard Time:ER:Africa/Asmera: >> +E. Africa Standard Time:ER:Africa/Asmara: >> E. Africa Standard Time:ET:Africa/Addis_Ababa: >> E. Africa Standard Time:KM:Indian/Comoro: >> E. Africa Standard Time:MG:Indian/Antananarivo: >> @@ -101,10 +101,10 @@ >> FLE Standard Time:FI:Europe/Helsinki: >> FLE Standard Time:LT:Europe/Vilnius: >> FLE Standard Time:LV:Europe/Riga: >> -FLE Standard Time:001:Europe/Kiev: >> +FLE Standard Time:001:Europe/Kyiv: >> Fiji Standard Time:001:Pacific/Fiji: >> GMT Standard Time:ES:Atlantic/Canary: >> -GMT Standard Time:FO:Atlantic/Faeroe: >> +GMT Standard Time:FO:Atlantic/Faroe: >> GMT Standard Time:GG:Europe/Guernsey: >> GMT Standard Time... > > make/jdk/src/classes/build/tools/cldrconverter/TimeZoneParseHandler.java line > 45: > >> 43: class TimeZoneParseHandler extends AbstractLDMLHandler<Object> { >> 44: private static final String PREF_PREFIX = "preferred:"; >> 45: private final Map<String, String> ianaAliasMap = >> HashMap.newHashMap(32); > > To give a sense of understanding, I recommend adding a comment indicating > that the size of the `ianaAliasMap` can be estimated from the number of > `iana` attributes present in _timezone.xml_. Including the CLDR version in > this comment would help with locating and updating the size when CLDR data is > upgraded in the JDK.
Separately, the size of the map seems to be 45 (and 26 when adding the identity check I noted below). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29591#discussion_r2771444477
