When Moditect adds elements to an existing JAR file, it uses ZipFileSystem instead of the older ZipOutputStream. Unfortunately this has a big drawback:

• JARs generated on systems that only differ by the setting of the default time zone are not identical.

The reason behind this is due to JDK internals:

• The old ZipEntry#setTime/setLastModifiedTime methods use java.util.zip.ZipUtils#javaToExtendedDosTime method, which is independent from the system default time zone,
• The new ZipFileSystem on the other hand uses jdk.nio.zipfs.ZipUtils#javaToDosTime method, which depends on the system default time zone.

Reproduction

To reproduce this problem use any recent project that uses Moditect, e.g. apache/commons-logging and build it using two different time zones.

On my Debian system with JDK 17 I obtain:

piotr@bialykiel:~/workspace/commons-logging$ git checkout rel/commons-logging-1.3.0
...
piotr@bialykiel:~/workspace/commons-logging$ export TZ=Europe/Warsaw
piotr@bialykiel:~/workspace/commons-logging$ mvn clean package
...
piotr@bialykiel:~/workspace/commons-logging$ sha256sum target/commons-logging-1.3.0.jar 
8590cef7d2810aef40334472696e11e3c0c97d6230a3eacaf685e74dc982d5ae  target/commons-logging-1.3.0.jar
piotr@bialykiel:~/workspace/commons-logging$ export TZ=America/Chicago
piotr@bialykiel:~/workspace/commons-logging$ mvn clean package
...
piotr@bialykiel:~/workspace/commons-logging$ sha256sum target/commons-logging-1.3.0.jar 
63ed3b7e92347ffe895d58ab72484af700c132e26206d6a4811d48d9f5c9462d  target/commons-logging-1.3.0.jar

The only difference is in the DOS time stamp of the entries modified by Moditect.