On Thu, 5 Feb 2026 17:27:22 GMT, Naoto Sato <[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:IE:Europe/Dublin:
> GMT Standard Time:IM:Europe/Isle_of_Man:
> @@ -115,7 +115,7 @@
> GTB St...
make/jdk/src/classes/build/tools/cldrconverter/CLDRConverter.java line 296:
> 294:
> 295: // Parse data independent of locales
> 296: parseBCP47();
Perhaps a comment either here or in `bcp47()` which indicates that parseBCP47
**must** precede `parseSupplemental()` such that the aliases can be derived
from _timezone.xml_ first.
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.
make/jdk/src/classes/build/tools/cldrconverter/TimeZoneParseHandler.java line
72:
> 70: if (iana != null) {
> 71: for (var a : alias.split("\\s+")) {
> 72: ianaAliasMap.put(a, iana);
I think we should add a check to not add `a` to the `ianaAliasMap` if `a` is
equal to `iana`, since the mapping would be identical. E.g. "Asia/Kolkata" ->
"Asia/Kolkata".
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/29591#discussion_r2771466800
PR Review Comment: https://git.openjdk.org/jdk/pull/29591#discussion_r2771442549
PR Review Comment: https://git.openjdk.org/jdk/pull/29591#discussion_r2771318244
