RFR: 8276766: Enable jar and jmod to produce deterministic timestamped content [v4]

[Andrew Leonard]

On Thu, 25 Nov 2021 19:21:36 GMT, John Neffenger <jgneff at openjdk.org> wrote:

>>> A user who’s not familiar with the lingo of [reproducible builds](https://reproducible-builds.org/docs/source-date-epoch/) will be mystified by an option named `--source-date`. A user who just wants to set the timestamp of new entries won’t be looking for an option whose name includes “source.”
>>> 
>>> Please consider providing a more general option, say `--date`, which takes an [ISO 8601 date/time string](https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/time/format/DateTimeFormatter.html#ISO_DATE_TIME). That would solve the general problem while also satisfying the requirement for reproducible builds. In the build it’s easy enough to convert the seconds-since epoch value of `SOURCE_DATE_EPOCH` to an ISO 8601 string (`date -d @$SOURCE_DATE_EPOCH --iso-8601=seconds`).
>> 
>> Thanks @mbreinhold , good point, i'll update to use --date=<iso-8601-date\>
>
>> Please consider providing a more general option, say `--date`, which takes an [ISO 8601 date/time string](https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/time/format/DateTimeFormatter.html#ISO_DATE_TIME).
> 
> The `jar` and `jmod` tools will need to truncate, restrict, or convert the time zone and fractional seconds permitted by the ISO 8601 date and time format.
> 
> The only way I found to store a timestamp using the methods of `java.util.zip.ZipEntry` that was independent of the system's time zone was by passing a local date and time in UTC to `setTimeLocal(LocalDateTime)`, truncated to seconds.
> 
> You can store a zoned date and time indirectly (in seconds) by adding an extra extended timestamp field to each entry with `setLastModifiedTime(FileTime)`. Unfortunately, that method also stores the "MS-DOS date and time" as the local date and time in the default time zone of the JVM (the time zone of the build machine). Furthermore, the extra field added to each entry increases the size of the archive.
> 
> The beauty of the `SOURCE_DATE_EPOCH` value is that it avoids any confusion in its interpretation while providing a straightforward solution to the only users ever known to need it.

@jgneff @LanceAndersen As John has pointed out there is a fundamental issue with the current ZipEntry API, in that for the conversion to/from (setTime()/getTime()) MS-DOS dostime it has to infer the time-zone from the current JVM default, so it can then workout the millis since epoch. Using set/getLocalDateTime() is only a half solution, that will only work as long as there isn't an extended FileTime being stored in the ZipEntry, which will occur for years  <1980 or >2106.

My updated PR proposes an extension to the ZipEntry API (and thus the CSR) to handle Zoned times for set/get, with the addition of the following API extensions to ZipEntry:
void setTimeZoned(ZonedDateTime)
ZonedDateTime getTimeZoned(ZoneId)
ZipEntry setLastModifiedTimeZoned(FileTime, ZoneId)
FileTime getLastModifiedTimeZoned(ZoneId)

Your thoughts are appreciated please?
Thanks

-------------

PR: https://git.openjdk.java.net/jdk/pull/6481