gnodet commented on code in PR #599:
URL: https://github.com/apache/maven-jar-plugin/pull/599#discussion_r4089111942
##########
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:
Good catch — the 2-second offset is NOT a fundamental MS-DOS time format
constraint. MS-DOS time stores seconds as `(second / 2)` in bits 0–4, so
`00:00:00` (all bits zero) is perfectly representable in the format. The reason
for `T00:00:02Z` is a JDK implementation quirk: `DOSTIME_BEFORE_1980 =
(1<<21)|(1<<16)` encodes exactly `1980-01-01 00:00:00` and is used as a
sentinel in `ZipEntry.setTime()` — when triggered, it causes extra timezone
metadata to be written into the ZIP (breaking reproducibility), which is the
bug described in JDK-8246129. The next instant representable in MS-DOS time
(2-second granularity) is `T00:00:02Z`, which avoids the sentinel. Fixed the
Javadoc in 51e6f65 to make this clearer.
--
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]
