When writing a jar file (or any zip file really), the zip handling code in the JDK copies last modified timestamps from files on the filesystem, which are in the form of milliseconds since epoch, to a local timestamp format supported by ZIP files. The former format is unambiguous, but the latter is not since it does not include a zone offset.
For example, when changing from daylight saving time to winter time the clocks are put back an hour, and we effectively experience the same hour twice. A local date time pointing somewhere in that hour is thus ambiguous, since we don't know whether it's the first or second occurrence of that local time. When extracting a jar file, we reconstruct the original file system timestamp in order to set it as last modified time on the extracted file. `ZipUtils::dosToJavaTime` calls `ZoneId.systemDefault().getRules().getOffset(...)`, which for a local date time that falls inside a DST transition will _always_ pick the offset corresponding to the _first_ instance of that time during that transition. The test sets the last modified time on several files to epoch timestamps that are an offset from the current time. If one of these timestamps is the _second_ instance of that local time during a DST transition, it will mismatch the time we end up with after extracting the jar file, since the extraction process will always pick the first occurrence of the local date time found in the ZIP file to derive a time zone offset from. As a result the test fails. There have over the years been a number of changes to this test to handle DST changes, but they are incomplete. They only check whether a change happened while running the test itself, but don't check whether the derived time stamps used for testing are ambiguous. Rather than adding another bandaid to the test, I've opted for setting the system timezone to UTC for the jar invocations in this test (using the documented `user.timezone` property [1]). UTC has no daylight saving time, and every local time is unambiguous, so we shouldn't have this problem again. I've also removed the existing workarounds for DST changes. This also avoids the test from just being (partially) skipped if ran at the wrong moment. [1]: https://docs.oracle.com/en/java/javase/25/docs/api/java.base/java/util/TimeZone.html#user.timezone --------- - [x] I confirm that I make this contribution in accordance with the [OpenJDK Interim AI Policy](https://openjdk.org/legal/ai). ------------- Commit messages: - WIP Changes: https://git.openjdk.org/jdk/pull/33760/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=33760&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8395823 Stats: 63 lines in 1 file changed: 11 ins; 44 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/33760.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/33760/head:pull/33760 PR: https://git.openjdk.org/jdk/pull/33760
