On Thu, 2 Dec 2021 01:53:47 GMT, John Neffenger <jgn...@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. You're welcome. I did not test on *x64* macOS or Windows, by the way. I'll test JavaFX builds on those platforms as soon as this enhancement is included in an [early-access build][1]. [1]: https://jdk.java.net/18/ ------------- PR: https://git.openjdk.java.net/jdk/pull/6481
