On Thu, 5 Nov 2026 21:13:51 GMT, Jorn Vernee <[email protected]> wrote:
> 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, creates a jar file from those > files, extract it again, and checks whether the time stamps match. If one of > these timestamps is the _second_ instance of a local time during a DST > transition hour, 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... Thanks for the review! I've also updated the copyright year, added the bug id to the test, and added a comment to explain why we're adding the timezone flag to the jar file invocation. ------------- PR Comment: https://git.openjdk.org/jdk/pull/33760#issuecomment-6688204233
