*Problem:* PR https://github.com/openjdk/jdk/pull/6481 addresses the main problems with deterministic timestamping of Zip entries, with the introduction of a new --date <ISO-8601-date-time> option for jar & jmod. However, the ZipEntry timestamp is constructed from a combination of an MS-DOS timestamp and a FileTime(seconds since epoch). MS-DOS timestamp is used between 1980->2106, FileTime is used outside that range. The problem arises in deterministically setting the ZipEntry times within JVMs with different default system time-zones. This occurs because ZipEntry.setTime(long millisSinceEpoch) or setTimeLocal(LocalDateTime) are unaware of time-zones. So when setTime has to calculate the msdostime from millisSinceEpoch, it has to query the system time-zone to work out what the "date-time" is. Similarly, for setTimeLocal(LocalDateTime), if the LocalDateTime is outside 1980-2106 range, then it has to create a FileTime, hence again it has to use the system time-zone to work out how many seconds since epoch the LocalDateTime is.
*Solutions proposed so far:* 1. Take the --date <ISO-8601-datetime> value and create a LocalDateTime eg.1982-12-09T14:02:06, and call ZipEntry.setTimeLocal(with LocalDateTime"1982-12-09T14:02:06"). For the same input and across time-zones the ZipEntry is deterministic when within the valid MS-DOS time range (1980->2106), because no extended FileTime is created. Pros: - No API changes, uses existing ZipEntry.setTimeLoca(LocalDateTime) Cons: - Is only determinstic between years 1980->2106, outside this range a FileTime is generated using the system time-zone. 2. Add new "Zoned" set/get methods to ZipEntry, so that ZipEntry does not have to defer to the system time-zone. By adding set/getTimeZoned(ZonedDateTime), set/getLastModifiedTimeZoned(FileTime, ZoneId) methods to ZipEntry the ZipEntry MS-DOS time and extended FileTime can be set precisely and deterministically to the user supplied date-time. Pros: - ZipEntry is always deterministically created for the same input --date <ISO-8601-datetime>, across different JVM time-zones, for all time ranges. Cons: - An API addition is required to ZipEntry to add new "Zoned" set/get time methods. Thoughts, comments, or alternatives most welcome please? Thanks Andrew
