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

[Andrew Leonard]

On Tue, 30 Nov 2021 16:26:28 GMT, John Neffenger <jgneff at openjdk.org> wrote:

> > So what you suggest sounds reasonable, although it would be a "behaviour change" in that whereas now if the date is between 1980->2106 only a xdostime is stored, we would now always be storing the additional "mtime" field ...
> 
> No, sorry, that is not at all what I suggested.
> 
> I am suggesting to immediately convert the value of the `--date` command-line option to an `Instant`. Once you have an `Instant` object, it's just like before when you had the value of `SOURCE_DATE_EPOCH` (which is in fact an instant on the time line), so you can revert to using your prior revision that handled that situation just perfectly!
> 
> In fact, you always want to avoid storing the addition "extended timestamp" field when possible because it causes a rather surprising increase in the size of the archive.
> 
> I wanted to send this right away, because you're such a fast coder, and in a different time zone, but please give me some time to look over your and Jaikiran's comments in more detail this morning. Thanks! ��
@jgneff John, sorry got confused, but I see what you're saying now. So what you're saying is take the --date <iso8601>, work out a LocalDateTime for that "instant" but in UTC, then call e.setTimeLocal(localDateTime).
So I think i'm in fact just putting together a new commit for option (1) using setTimeLocal() similar to this, just very slightly different but efftecively doing the same thing, i'm converting the user input --date string to a ZonedDateTime, from which I get the LocalDateTime for calling setTimeLocal(zonedDateTime.toLocalDateTime()). That way when you unzip it the files have the same local date time.
eg.
--date="2022-03-15T14:36:00+06:00"

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

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