On Fri, 25 Sep 2026 22:21:34 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 219: > >> 217: >> 218: /* >> 219: * If DynamicDaylightTime is disabled or TimeZoneKeyName is unknown, > > I'd also clarify this comment to mention the third case when there is no > match found in the tzmappings as indicated by the return value of > `matchJavaTZ`. Will do. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/33052#discussion_r4120307768
