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

Reply via email to