On Fri, 25 Sep 2026 17:09:25 GMT, Naoto Sato <[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 222: > >> 220: * return a custom time zone name based on the GMT offset. >> 221: */ >> 222: customZoneName(dtzi.Bias, winZoneName, MAX_ZONE_CHAR); > > The old code was calling `getGMTOffsetID`, which takes care of dst offset. > The first argument should be offset by the value of `dtzi.DaylightBias` when > in DST. Good catch! I missed that. After reading the DYNAMIC_TIME_ZONE_INFORMATION documentation, I assumed that the Bias would have been adjusted by the DaylightBias already, but now I see that it's not the case. I'll update, ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/33052#discussion_r4120304423
