desruisseaux commented on code in PR #599:
URL: https://github.com/apache/maven-jar-plugin/pull/599#discussion_r4089080328
##########
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:
Does the 2 seconds granularity really requires that the time starts at 2
seconds? If we can store 2, we can store 0 with such granularity.
The Microsoft documentation for the [file time to dos date
time](https://learn.microsoft.com/en-us/windows/win32/api/winbase/nf-winbase-filetimetodosdatetime)
function said _"The MS-DOS date format can represent only dates between
1/1/1980 and 12/31/2107; this conversion fails if the input file time is
outside this range."_ without mentioning a starting time of 00:00:02.
Looking at the data structure, it seems that MS-DOS time is stored on 16
bits with 4 bits for the seconds divided by 2. There is nothing in this
structure preventing 0. Or is it a limitation of the ZIP format? Section 4.4.6
of [ZIP File Format
Specification](https://pkware.cachefly.net/webdocs/APPNOTE/APPNOTE-6.3.10.TXT)
does not mention it.
--
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]
