> 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...
Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: Add comment, add bugid, update copyright year ------------- Changes: - all: https://git.openjdk.org/jdk/pull/33760/files - new: https://git.openjdk.org/jdk/pull/33760/files/fb70c648..cc72965c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=33760&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=33760&range=00-01 Stats: 8 lines in 1 file changed: 6 ins; 0 del; 2 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
