[ https://issues.apache.org/jira/browse/MJAR-300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17816837#comment-17816837 ]
Herve Boutemy commented on MJAR-300: ------------------------------------ bq. What would be your recommendation? please try to use your code from different TZs and confirm that you get different binaries output. Then do what you prefer: pay one way or the other, there is no choice, zip format comes from DOS, that does not know what a TZ is: seconds are calculated from local time, not from UTC. Then defining {{outputTimestamp}} as UTC based makes zip binary dependent on current TZ bq. it would be good to document how the timestamps in the jar are derived when project.build.outputTimestamp is set. I found next to no documentation besides code. help welcome: explaining this in a way that people understand is hard (because it all start by explaining how timestamp is stored in zip with TZ-specific seconds because in fact it ignores TZ. And I won't even try to clarify how extended timestamp in zip file is done like Unix, this time really getting seconds from UTC: that is what lead to MSHADE-420) I tried in the past, and did not manage to make something that 2 people were able to agree on (and even myself have hard time to read after a few days whatever explanation I wrote) > maven jar plugin does not interpret build outputTimestamp correctly > ------------------------------------------------------------------- > > Key: MJAR-300 > URL: https://issues.apache.org/jira/browse/MJAR-300 > Project: Maven JAR Plugin > Issue Type: Bug > Affects Versions: 3.3.0 > Reporter: Henning Schmiedehausen > Priority: Major > > consider a minimal project that packages a jar: > % DATE=$(date -Iseconds) ; echo $DATE ; mvn -q clean package ; jar tvf > target/jartest-0.1-SNAPSHOT.jar > 2024-02-10T21:44:53-08:00 > 0 Sat Feb 10 21:44:54 PST 2024 META-INF/ > 568 Sat Feb 10 21:44:54 PST 2024 META-INF/MANIFEST.MF > 0 Sat Feb 10 21:44:54 PST 2024 META-INF/maven/ > 0 Sat Feb 10 21:44:54 PST 2024 META-INF/maven/jartest/ > 0 Sat Feb 10 21:44:54 PST 2024 META-INF/maven/jartest/jartest/ > 5 Sat Feb 10 21:44:54 PST 2024 testfile.txt > 575 Sat Feb 10 21:39:50 PST 2024 META-INF/maven/jartest/jartest/pom.xml > 56 Sat Feb 10 21:44:54 PST 2024 > META-INF/maven/jartest/jartest/pom.properties > Note how the timestamp returned by the date command and the timestamps of the > entries in the jar are basically the same (around 21:44:53 - 21:44:54 on Feb > 10th, 2024) > Now use that date as the project build timestamp: > DATE=$(date -Iseconds) ; echo $DATE ; mvn -q > -Dproject.build.outputTimestamp=$DATE clean package ; jar tvf > target/jartest-0.1-SNAPSHOT.jar > 2024-02-10T21:46:30-08:00 > 0 Sun Feb 11 05:46:30 PST 2024 META-INF/ > 568 Sun Feb 11 05:46:30 PST 2024 META-INF/MANIFEST.MF > 0 Sun Feb 11 05:46:30 PST 2024 META-INF/maven/ > 0 Sun Feb 11 05:46:30 PST 2024 META-INF/maven/jartest/ > 0 Sun Feb 11 05:46:30 PST 2024 META-INF/maven/jartest/jartest/ > 5 Sun Feb 11 05:46:30 PST 2024 testfile.txt > 575 Sun Feb 11 05:46:30 PST 2024 META-INF/maven/jartest/jartest/pom.xml > 56 Sun Feb 11 05:46:30 PST 2024 > META-INF/maven/jartest/jartest/pom.properties > > The timestamp and the entries in the jar differ by eight hours (the offset of > my local timezone). > When forcing UTC: > DATE=$(TZ=UTC date -Iseconds) ; echo $DATE ; mvn -q > -Dproject.build.outputTimestamp=$DATE clean package ; jar tvf > target/jartest-0.1-SNAPSHOT.jar > 2024-02-11T05:48:22+00:00 > 0 Sun Feb 11 05:48:22 PST 2024 META-INF/ > 568 Sun Feb 11 05:48:22 PST 2024 META-INF/MANIFEST.MF > 0 Sun Feb 11 05:48:22 PST 2024 META-INF/maven/ > 0 Sun Feb 11 05:48:22 PST 2024 META-INF/maven/jartest/ > 0 Sun Feb 11 05:48:22 PST 2024 META-INF/maven/jartest/jartest/ > 5 Sun Feb 11 05:48:22 PST 2024 testfile.txt > 575 Sun Feb 11 05:48:22 PST 2024 META-INF/maven/jartest/jartest/pom.xml > 56 Sun Feb 11 05:48:22 PST 2024 > META-INF/maven/jartest/jartest/pom.properties > The timestamp is "correct" but I passed it in as UTC but the jar plugin > considers it "local time" and silently attaches PST as timezone. This is > where the eight hours discrepancy come from. > This seems to be specific to the outputTimestamp parsing of the jar plugin. > > > > > > > > -- This message was sent by Atlassian Jira (v8.20.10#820010)