gnodet-bot commented on code in PR #599:
URL: https://github.com/apache/maven-jar-plugin/pull/599#discussion_r4089108637
##########
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:
@desruisseaux — You are correct on all three points:
1. **MS-DOS time CAN represent 0 seconds**: The 4-bit seconds field encodes
seconds ÷ 2, so 0b0000 = 0 seconds is valid. 1980-01-01T00:00:00Z is
representable in DOS time — the ZIP spec (§4.4.6) and Microsoft's
FileTimeToDosDateTime documentation say nothing about a 2-second minimum.
2. **The 2-second minimum is a JDK `jar` tool decision**: The openjdk/jdk
[PR #6481](https://github.com/openjdk/jdk/pull/6481) discussion (specifically
[this
comment](https://github.com/openjdk/jdk/pull/6481#issuecomment-983199820))
explains why: Java's `ZipEntry` uses the MS-DOS time value `0x210000` (which
corresponds to 1980-01-01T00:00:00Z, i.e. all-zero time bits with the date bits
set to the minimum) as a `DOSTIME_BEFORE_1980` sentinel to flag pre-1980
entries. To avoid ambiguity — a legitimate 1980-01-01T00:00:00Z timestamp would
be indistinguishable from the sentinel — the JDK `jar` tool deliberately chose
00:00:02Z as the minimum, one even-second step past the sentinel.
3. **The current Javadoc is imprecise**: Saying `"whose earliest
representable value maps to 1980-01-01T00:00:02Z — not T00:00:00Z"` implies
this is a ZIP/MS-DOS format constraint, which it is not. A more accurate
wording would be:
```
The ZIP format stores entry timestamps in MS-DOS time format, which has
2-second
granularity; the earliest representable value is 1980-01-01T00:00:00Z.
However,
the JDK {@code jar} tool requires at least 1980-01-01T00:00:02Z to avoid
ambiguity
with the sentinel value used internally by {@code ZipEntry} for pre-1980
timestamps.
```
This is a Javadoc accuracy issue — the clamping logic and the constant value
(315532802L) are both correct. Only the explanation of *why* the minimum is
00:00:02 (not 00:00:00) needs updating.
_This comment was generated by an AI agent, Hermès on behalf of @gnodet._
<!-- reviewer: gnodet-bot -->
--
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]
