On Fri, 25 Sep 2026 22:53:10 GMT, Justin Lu <[email protected]> wrote:

>> Simplify the system TimeZone retrieval.
>> 
>> The new code behaves just as before in the most common case where 
>> `GetDynamicTimeZoneInformation` returns a known `TimeZoneKeyName`, and 
>> reduces the amount of second-guessing when the time zone is not known.
>> 
>> Method `getGMTOffsetID` was not modified. It is only used as a fallback when 
>> `findJavaTZ_md` fails, and while it doesn't look great, it's probably better 
>> than most of the alternatives.
>> 
>> I verified that:
>> - the `TimeZoneKeyName` contains non-localized values and is usable on both 
>> English and non-English systems,
>> - tier1 and tier2 tests continue to pass
>> - java/time tests continue to pass when the fallback paths are taken 
>> (`findJavaTZ_md` returns a `customZoneName` or a `NULL`)
>> 
>> ---------
>> - [x] I confirm that I make this contribution in accordance with the 
>> [OpenJDK Interim AI Policy](https://openjdk.org/legal/ai).
>
> src/java.base/windows/native/libjava/TimeZone_md.c line 171:
> 
>> 169:         }
>> 170:         wcstombs(winZoneName, dtzi.TimeZoneKeyName, MAX_ZONE_CHAR);
>> 171:         return VALUE_KEY;
> 
> From what I can see in these changes is that the new code basically ends all 
> fallback logic right around here. All the further registry discovery logic is 
> instead replaced with a custom zone name with the fixed offset.
> 
> Does this type of behavior change require a RN? Or is this something too 
> obscure to describe, or since the removed path was for older Windows 
> versions, it has been non-functional for a long time anyway.

That's correct; the new code assumes that the GetDynamicTimeZoneInformation 
call will return a TimeZoneKeyName entry on success. This is true on Windows 
2016 and Windows 11 at least. 

The removed fallback deals with a case where the GetDynamicTimeZoneInformation 
succeeds, but returns information with an empty key name. This can happen when 
the registry value 
`HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\TimeZoneInformation\TimeZoneKeyName`
 is missing. I don't think we need to support that case.

I don't think this needs a RN, but I could be convinced otherwise.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/33052#discussion_r4120764584

Reply via email to