On Mon, 28 Sep 2026 09:51:25 GMT, Daniel Jeliński <[email protected]> wrote:
>> 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. Thanks for the explanation. Given the removed fallback isn't relevant on modern Windows versions, I'd agree this does not need an RN. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/33052#discussion_r4124420814
