Small reminder: if you want to be reproducible you must fix the timestamp so whatever zone, whatever format works. It is common to use new Date(1000) in utc but not important at the end.
Side note: same applies for most of the env though (locale for ex.). Le dim. 6 oct. 2019 à 22:57, Tibor Digana <tibordig...@apache.org> a écrit : > Hi Emmanuel, > > >> The point is, two developers may generate a different pom if the local > timezone is used. > > very well explained! It could not be better: utc time is the same however > the text is different and that's important for the stream identity. > Karl had a proposal with additional property "format" as a compromise. > Is the geography a localization important information for the behavior of > reproducible build? IMO, it is not! > So why not to have Karl's format NULL by default, means the UTC. > > btw, there is whole bunch of problems with time with/out TZ in webapps and > rdbms databases and cloud system and distributed HTTP clients but that's > another story. > > > >> I suspect that if the jar includes the pom it'll break its > reproducibility too > > Actually, there is "pom.properties" in META-INF folder of the JAR archive > artifact and this file containes the comment having the system time > generated by JDK. > There's a PR for this issue. The POM and the properties file are both > embedded in META-INF. > > > Cheers > Tibor17 > > On Sun, Oct 6, 2019 at 10:19 PM Emmanuel Bourg <ebo...@apache.org> wrote: > > > Le 06/10/2019 à 20:13, Hervé BOUTEMY a écrit : > > > > > no, it does not add any dependency on developer configuration: > > > 2019-10-05T18:37:42Z == 2019-10-05T20:37:42+02:00 == > > 2019-10-05T16:37:42-02:00 > > > > yes but: > > > > "2019-10-05T18:37:42Z" != "2019-10-05T20:37:42+02:00" != > > "2019-10-05T16:37:42-02:00" > > > > The point is, two developers may generate a different pom if the local > > timezone is used. A fixed timezone is necessary to ensure the pom itself > > is reproducible. > > > > > > > when will this value be written in the pom.xml is independant: > > currently, in > > > my PoC, I wrote the values by hand. In the future, it will probably be > > updated > > > by maven-release-plugin, and we'll have to choose if the timestamp is > > written > > > in Z or if it is written in local timezone with its offset: both ways > of > > > expressing the timestamp are valid and will give reproducible result > > > > The jar generated is reproducible, but not the pom. I suspect that if > > the jar includes the pom it'll break its reproducibility too (this is > > the default for maven-jar-plugin, but I don't know if it embeds the > > original pom without the timestamp, or the generated pom with the > > timestamp). > > > > > > > once again, war files taken apart for web servers, who looks at > > timestamp in > > > zip files? > > > > archive timestamps are just the tip of the iceberg. There are more > > visible timestamps elsewhere, for example in the javadoc headers, in > > .properties files, in OSGi attributes, sometimes in the source files... > > > > Emmanuel Bourg > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > > For additional commands, e-mail: dev-h...@maven.apache.org > > > > >
