On Thu, 25 Nov 2021 19:21:36 GMT, John Neffenger <jgn...@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
