takari-lifecycle jar entries timestamp depends on user's timezone

[hboutemy]

we can force a timezone when repbuilding for Reproducible Builds, like https://github.com/jvm-repo-rebuild/reproducible-central/blob/master/content/io/takari/maven/maven-timeline/maven-timeline-2.0.0.buildspec

but this is not ideal (not a blocker like #171): it would be easier to have a zip output that is independent from user's timezone

here is what is done in plexus-archiver to solve this: https://github.com/codehaus-plexus/plexus-archiver/blob/master/src/main/java/org/codehaus/plexus/archiver/zip/AbstractZipArchiver.java#L688

[cstamas]

Am unsure I get this issue: it is ZIP format that have no notion of time zone. Takari stores timestamps with "dos epoch", and it is on unpack that TZ shift may occur (and not on creation).

From ZIP: "The ZIP format has no notion of time zone, so timestamps are only meaningful if it is known what time zone they were created in."

Moreover, Takari uses constant timestamp the "doc epoch": https://github.com/jvanzyl/provisio-archiver/blob/4d4bb73e90c4bf6443177d5215e1548dce13a1c6/src/main/java/ca/vanzyl/provisio/archive/Archiver.java#L25 (in millis, so UTC).

Hence, ZIP files created by Takari Lifecycle (Takari Archiver) are always having same (local) timestamp, but unpacker MAY shift them (given they are local), no?

[hboutemy]

"dos epoch" is GMT based, Java converts it to local time before storing the local time in zip binary: this is how user's timezone influences bytes saved into the zip file = what we experience when we check bit-for-bit reproducibility of the zip bytes

[hboutemy]

just test building with -Duser.timezone='Etc/UTC+..' with different values and you will see how the output binary currently changes
target is that it is stable...

[cstamas]

This needs new takari-archiver, fix is here jvanzyl/provisio-archiver#34