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

[Andrew Leonard]

On Tue, 30 Nov 2021 20:00:19 GMT, John Neffenger <jgneff at openjdk.org> wrote:

> > Whichever we use, we have to use e.setTimeLocal(), so can't see what the difference is?
> 
> Okay, here's a brief command-line example before posting the code example. In my experience, most people trying to set up a common, project-wide build timestamp use the formatted string in UTC:
> 
> ```
> $ date -d @$SOURCE_DATE_EPOCH --iso-8601=seconds --utc
> 2021-11-29T17:36:06+00:00
> ```
> 
> In JavaFX, we're using the more concise Java version of that string: `2021-11-29T17:36:06Z`.
> 
> So here's what happens when you get that exact same instant in time from different sources on different machines:
> 
> ```
> $ TZ=America/Nome date -d @$SOURCE_DATE_EPOCH --iso-8601=seconds
> 2021-11-29T08:36:06-09:00
> $ TZ=Europe/Rome date -d @$SOURCE_DATE_EPOCH --iso-8601=seconds
> 2021-11-29T18:36:06+01:00
> $ git log -1 --pretty=%cI
> 2021-11-29T09:36:06-08:00
> ```
> 
> All of a sudden it makes a big difference when you're discarding the time zone. You end up with differences in the archive files depending on (a) the time zone of the build machine, and (b) the source you use to obtain an ISO 8601 string to represent that singular instant.

AH! got ya, so I was looking at the requirement from a slightly different perspective, ie. reproducibility is same input == same output, so to my mind:
--date "2021-11-29T08:36:06-09:00"
is a different input to:
--date "2021-11-29T09:36:06-08:00"

ie. the String is different! but as you say, the use case is actually same input === "same INSTANT in TIME", my mind was totally not seeing that, thank you!
ok all makes sense now :-)

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

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