[
https://issues.apache.org/jira/browse/MJAR-300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17816837#comment-17816837
]
Herve Boutemy edited comment on MJAR-300 at 2/13/24 12:59 AM:
--------------------------------------------------------------
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 perfect 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)
was (Author: hboutemy):
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)
