On Fri, 6 Nov 2026 15:19:14 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 c... > > Jorn Vernee has updated the pull request incrementally with one additional > commit since the last revision: > > Add comment, add bugid, update copyright year looks good Jorn ------------- Marked as reviewed by lancea (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/33760#pullrequestreview-5802488124
