gnodet commented on code in PR #599:
URL: https://github.com/apache/maven-jar-plugin/pull/599#discussion_r4089107872
##########
src/main/java/org/apache/maven/plugins/jar/AbstractJarMojo.java:
##########
@@ -50,6 +50,16 @@
* @author Martin Desruisseaux
*/
public abstract class AbstractJarMojo implements
org.apache.maven.api.plugin.Mojo {
+ /**
+ * Minimum Unix time (seconds since epoch) accepted by the {@code jar}
tool.
+ * The ZIP format requires entry timestamps ≥ 1980-01-01. The JDK {@code
jar} tool
+ * uses MS-DOS time internally, which has 2-second granularity and whose
earliest
+ * representable value maps to 1980-01-01T00:00:02Z — not T00:00:00Z.
Review Comment:
You are correct that the MS-DOS time format itself can represent `00:00:00`
— the seconds field (bits 0–4) stores seconds/2, so a value of 0 is valid. The
2-second granularity is not the reason for the `T00:00:02Z` lower bound.
The real reason is a JDK-specific constraint: `1980-01-01T00:00:00Z` is the
`DOSTIME_BEFORE_1980` sentinel in the JDK ZIP implementation. Using that exact
value causes extra timezone metadata to be embedded in the archive, breaking
reproducibility (see
[JDK-8246129](https://bugs.openjdk.org/browse/JDK-8246129), fixed in JDK 15).
As a result, the JDK `jar` tool explicitly enforces that timestamps passed via
`--date` fall in the range `1980-01-01T00:00:02Z` to `2099-12-31T23:59:59Z` —
`T00:00:00Z` and `T00:00:01Z` are rejected. This is also documented in the
[reproducible-builds mailing
list](https://lists.reproducible-builds.org/pipermail/rb-general/2026-February/004045.html).
The Javadoc was misleading in attributing this to MS-DOS format's "earliest
representable value". Fixed in ed978de — now reads: *`1980-01-01T00:00:00Z` is
a sentinel value (`DOSTIME_BEFORE_1980`) in the JDK ZIP implementation that
causes extra timezone metadata to be written, breaking reproducibility (see
JDK-8246129). The next valid instant with 2-second MS-DOS granularity is
therefore `T00:00:02Z`.*
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
