On Tue, 30 Nov 2021 08:53:03 GMT, John Neffenger <jgn...@openjdk.org> wrote:
>> @andrew-m-leonard Thank you, Andrew, for your bold solution to Mark's >> request -- one that even solves the problem with the current `ZipEntry` API! >> >> Would you be willing to consider a minor change to your implementation? >> >> As I mentioned earlier, if we are going to allow an ISO 8601 zoned date and >> time, we need either to **truncate, restrict, or convert** its value. The >> current implementation **truncates,** discarding the time zone information. >> The better option might be to **convert.** That is, parse the ISO 8601 >> string with `Instant.parse`, get the seconds since the epoch with >> `getEpochSecond`, and then proceed as before. Treat the value of `--date` as >> an instant on the time line, just like `SOURCE_DATE_EPOCH`, and always store >> its value in UTC. >> >> This also solves the problem of storing dates before 1980 as a local date >> and time in UTC while storing those after 1980 as a local date and time with >> a discarded time zone. By converting instead of truncating, the value is >> always stored as the local date and time in UTC regardless of whether or not >> it's within the range of the "MS-DOS date and time" field. >> >> Those of us using the timestamp of the last commit can still get the value >> directly from `git`. >> >> For `SOURCE_DATE_EPOCH`, run: >> >> >> $ git log -1 --pretty=%ct >> 1638207366 >> >> >> For the `--date` option of the `jar` and `jmod` tools, run: >> >> >> $ git log -1 --pretty=%cI >> 2021-11-29T09:36:06-08:00 >> >> >> Specifically, that `git` ISO 8601 string, and even the sample `date` command >> that Mark shows in his comment, are what break the current implementation by >> creating archives that depend on the time zone of the build machine again. >> >> By the way, the `jar` utility displays a time zone in the output of its >> `--list` and `--verbose` options even when there is no time zone information >> in the file. (In other words, it lies, or at least embellishes.) Use the >> verbose output of `zipinfo` to see the true values of the timestamps in an >> archive. > >> Would you be willing to consider a minor change to your implementation? > > Just to be clear, this change should let us postpone any additions to the > `ZipEntry` API for another day, if at all, and maybe even get this pull > request integrated for JDK 18. @jgneff John, i'm going to update this PR to use the LocalDateTime setting option and restrict --date to 1980->2099, thus ensuring xdostime is always only used. This I believe we should be able to get into jdk-18. ------------- PR: https://git.openjdk.java.net/jdk/pull/6481
