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

[John Neffenger]

On Wed, 1 Dec 2021 21:50:46 GMT, Andrew Leonard <aleonard at openjdk.org> wrote:

> I can adjust the --date value validation to be > 1980-01-01T00:00:00Z ?

I know, nit picky, right? �� I'll take no offense if you ignore it. The thing is, everyone else implementing this feature gave that specific instant a wide margin. (See my previous comment about Debian and Gradle.) Debian adds 12 hours 1 minute just to avoid it (`1980-01-01T12:01:00Z`), while Gradle even skips to the next month (`1980-02-01T00:00:00`).

Because developers looking into this discover the magic earliest date, some may think it's a great choice for a default deterministic value and use it! Then this current implementation breaks with no warning. If you add one second, the `ZipEntry` method rounds down, and you get the exact same "DOS date and time" in the output (1980 Jan 1 00:00:00), but now it works. Kind of confusing.

So my latest recommendation is to define the earliest permitted instant at `1980-01-01T00:00:02Z` to avoid any possibility of setting the magic local date and time at all. The Gradle folks might explain it better in [their comment here][1].

[1]: https://github.com/gradle/gradle/blob/master/subprojects/core/src/main/java/org/gradle/api/internal/file/archive/ZipCopyAction.java#L42-L56

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

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