<i18n dev> RFR: 8377013: TimeZone.getDefault() returns obsolete id on Windows (Asia/Calcutta)

[Justin Lu]

On Thu, 5 Feb 2026 22:32:16 GMT, Justin Lu <jlu 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...
>
> 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