Timestamps inside the -all.jar are all 02-01-1980

[breedx-splk]

Follow-up issue from #2459

Timestamps of all the files inside the jar are all 02-01-1980.

Archive:  opentelemetry-javaagent-0.17.0-all.jar
  Length      Date    Time    Name
---------  ---------- -----   ----
        0  02-01-1980 00:00   META-INF/
      461  02-01-1980 00:00   META-INF/MANIFEST.MF
        0  02-01-1980 00:00   META-INF/licenses/
    39254  02-01-1980 00:00   META-INF/licenses/licenses.md
        0  02-01-1980 00:00   META-INF/licenses/byte-buddy-1.10.18.jar/
        0  02-01-1980 00:00   META-INF/licenses/byte-buddy-1.10.18.jar/META-INF/
    10301  02-01-1980 00:00   META-INF/licenses/byte-buddy-1.10.18.jar/META-INF/LICENSE
      567  02-01-1980 00:00   META-INF/licenses/byte-buddy-1.10.18.jar/META-INF/NOTICE
        0  02-01-1980 00:00   META-INF/licenses/byte-buddy-agent-1.10.18.jar/
        0  02-01-1980 00:00   META-INF/licenses/byte-buddy-agent-1.10.18.jar/META-INF/
    10140  02-01-1980 00:00   META-INF/licenses/byte-buddy-agent-1.10.18.jar/META-INF/LICENSE
      567  02-01-1980 00:00   META-INF/licenses/byte-buddy-agent-1.10.18.jar/META-INF/NOTICE
<etc>

This is odd and misleading, and people sometimes want to actually know/verify times of certain files.

Ideally, even when being shaded, the files would retain their original timestamps.

[laurit]

I believe that this is done to make builds reproducible. Removing

tasks.withType(AbstractArchiveTask) {
  preserveFileTimestamps = false
  reproducibleFileOrder = true
}

from gradle/java.gradle might get the timestamps back.

[iNikem]

reproducibleFileOrder is certainly desirable. And I don't think we should remove preserveFileTimestamps as well. But if we do, then we have to make sure this does not break Gradle build cache.

[breedx-splk]

What about settings preserveFileTimestamps = true instead of removing it? Isn't that what we want?

[iNikem]

What about settings preserveFileTimestamps = true instead of removing it? Isn't that what we want?

These two options are equivalent, aren't they?

[breedx-splk]

What about settings preserveFileTimestamps = true instead of removing it? Isn't that what we want?

These two options are equivalent, aren't they?

I dunno, but isn't it better to be explicit here rather than requiring the reader to know how gradle might have chosen to implement an obscure default?

[iNikem]

I bet nobody will be interested in that detail until some problem happens :) In general I prefer not to explicitly set a value which is already a default one.

[iNikem]

@open-telemetry/java-approvers @breedx-splk do we still think of this issue as important? I am tempted to close it.

[breedx-splk]

$ curl -qsL https://github.com/open-telemetry/opentelemetry-java-instrumentation/releases/download/v1.6.0/opentelemetry-javaagent-all.jar | jar tv | head
     0 Fri Feb 01 00:00:00 PST 1980 META-INF/
   460 Fri Feb 01 00:00:00 PST 1980 META-INF/MANIFEST.MF
     0 Fri Feb 01 00:00:00 PST 1980 io/
     0 Fri Feb 01 00:00:00 PST 1980 io/opentelemetry/
     0 Fri Feb 01 00:00:00 PST 1980 io/opentelemetry/javaagent/
     0 Fri Feb 01 00:00:00 PST 1980 io/opentelemetry/javaagent/shaded/
     0 Fri Feb 01 00:00:00 PST 1980 io/opentelemetry/javaagent/shaded/instrumentation/
     0 Fri Feb 01 00:00:00 PST 1980 io/opentelemetry/javaagent/shaded/instrumentation/api/
[...]

It's still an issue. As far as relative priority, probably not high. But incorrect. Closing this will increase the likelihood of it never getting fixed.

[iNikem]

Why is this an issue? why files timestamps inside jar are important?

[breedx-splk]

Same reason that filesystems have timestamps...it indicates when a file was last modified. Same reasons I gave in the original issue description. I've needed to dissect jar contents before, and when the timestamps are all broken it makes it that much harder to compare inputs and outputs.

I think it's also just a bad look that weakens confidence in the build process being good. I dunno. I'll close since I seem to be the only one that cares...if one other person out there cares, then we can reopen.

[trask]

I think it's also just a bad look that weakens confidence in the build process being good

👍

if one other person out there cares, then we can reopen

(re-opening)

[iNikem]

I think it's also just a bad look that weakens confidence in the build process being good

👍

I don't understand this argument :) E.g. jib also by default creates image with timestamp equal to start of the epoch. For the same reason: build reproducibility. I don't understand how this means "bad build process" :)