8276766: Discuss options for deterministic jar/jmod timestamps across timezones

[Andrew Leonard]

*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