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

[Andrew Leonard]

On Thu, 2 Dec 2021 01:53:47 GMT, John Neffenger <jgneff at openjdk.org> wrote:

>>> I'm testing it now. So far, it's working great!
>>> 
>>> I found one boundary problem. The magic instant of `1980-01-01T00:00:00Z` triggers an extended header with the wrong time:
>>> 
>>> ```
>>>   file last modified on (DOS date/time):          1980 Jan 1 00:00:00
>>>   file last modified on (UT extra field modtime): 1980 Jan 1 00:00:00 local
>>>   file last modified on (UT extra field modtime): 1980 Jan 1 08:00:00 UTC
>>> ```
>>> 
>>> One second later `1980-01-01T00:00:01Z` works fine (considering the rounding down to even seconds):
>>> 
>>> ```
>>>   file last modified on (DOS date/time):          1980 Jan 1 00:00:00
>>> ```
>> 
>> Thanks John. The 1980-01-01T00:00:00Z is a known issue because the zip xdostime format uses that value as the "marker" for date before-1980. I can adjust the --date value validation to be >  1980-01-01T00:00:00Z ?
>
>> 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

@jgneff thank you John, for your help with this as well, your platform testing has been most useful as well.
I've Proposed the CSR now (https://bugs.openjdk.java.net/browse/JDK-8277755), so that should go through the approval process..
@AlanBateman @LanceAndersen i'd also like to get your final reviews as well please?
Many thanks
Andrew

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

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