On Tue, 30 Nov 2021 20:00:19 GMT, John Neffenger <jgn...@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
