On Thu, 24 Sep 2026 11:37:41 GMT, Daniel Jeliński <[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). Thanks for looking into this, Daniel 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. ------------- PR Review: https://git.openjdk.org/jdk/pull/33052#pullrequestreview-5320469595 PR Review Comment: https://git.openjdk.org/jdk/pull/33052#discussion_r4106863464
