On Mon, 29 Nov 2021 19:27:57 GMT, Andrew Leonard <aleon...@openjdk.org> wrote:
>>> @AlanBateman yes, see above comment, thanks >> >> This is a significant change to the ZipEntry API that will require >> discussion and agreement. Can you start a discussion on core-libs-dev about >> the topic? You could start with a summary of the problem and the API and >> non-API options that have been explored. > >> > > @AlanBateman yes, see above comment, thanks >> > >> > >> > This is a significant change to the ZipEntry API that will require >> > discussion and agreement. Can you start a discussion on core-libs-dev >> > about the topic? You could start with a summary of the problem and the API >> > and non-API options that have been explored. >> >> I agree with Alan. We are too close to RDP 1 to consider this type of change >> for JDK 18 as we need more time to discuss, update the CSR, test (and we >> will need additional tests for this), and give it time to bake. IMHO this >> will need to go into JDK 19 assuming we move forward with changes similar to >> the latest commit > > Thanks @LanceAndersen , @AlanBateman, i've just posted a discussion thread > here: > https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-November/084150.html @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. ------------- PR: https://git.openjdk.java.net/jdk/pull/6481
