<i18n dev> RFR: 8377013: TimeZone.getDefault() returns obsolete id on Windows (Asia/Calcutta)
Justin Lu
jlu at openjdk.org
Thu Feb 5 22:53:04 UTC 2026
On Thu, 5 Feb 2026 17:27:22 GMT, Naoto Sato <naoto at openjdk.org> 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
More information about the i18n-dev
mailing list