Creation time being 44 years ago is confusing

[schneems]

Mentioned in #6 (comment). A user might want to know "I built 5 images and can't remember which one was 5 minutes ago and which was 5 days ago" and want to use creation time to answer that question. However, this is not a bug, and pack is doing this intentionally, as @runesoerensen mentioned https://github.com/buildpacks/spec/blob/platform/0.13/platform.md#build-reproducibility.

At a minimum we could call out this behavior in our tutorials. We've been talking about it internally here's some observations:

Or maybe there's an opportunity to upstream a change to the docker CLI tooling, like instead of showing "44 years" show something like "Relative" or "Constant" or something more representative if others are doing this as well

Or possibly show the actual build time difference (somehow) while separating the inner build time for cache reasons. I think people might expect to be able to view images they've made and see which was made 10 minutes ago versus 20 minutes ago if they forgot and showing a fixed time breaks that ability.

pack build now supports a --creation-time to override the time.
One option would be to upstream a change in defaults, such that instead of defaulting to unixtime zero, it defaults to something else that's still mostly deterministic. eg MAX(git commit time, builder timestamp, run image timestamp) (or similar)

Or just have it default to now() and advertised --creation-time as a way to create deterministic images.

It might also be a bit confusing that the default creation time isn't actually unix time zero, but rather epoch + 10 years https://github.com/buildpacks/imgutil/blob/9f7b96c3d09d7fbdb25f057b1a90c331c7c05deb/new.go#L61

Some pros/cons listed in this RFC https://github.com/buildpacks/rfcs/blob/822d70252536a5fe87db879bd38e87fde169c261/text/0103-source-date-epoch.md?plain=1#L3

Maybe we could link to this blog post in a FAQ for users or something https://medium.com/buildpacks/time-travel-with-pack-e0efd8bf05db

Also mentioned, that zip has date compatibility constraints https://github.com/heroku/buildpacks-python/blob/de378063c83e1eec6302e79f93f189162b5bbbbf/src/layers/python.rs#L416-L419.

[schneems]

Another option: If we moved this behavior out of pack (or made it not the default) I think it's possible to manually change file properties (such as mtime). In another discussion I proposed a language-independent lint tool that could possibly help catch such issues: run a build, grab all image SHAs, do another build and compare image SHAs then warn/error on the results.

I think having consistent image SHAs is really valuable for any app-independent layers such as the Ruby or Node binary layer which could (in theory) be safely shared.

[schneems]

Question: The Ruby buildpack uses mtime of files to determine least recently used assets. Is that silently broken due to this current behavior?

[edmorley]

Does the Ruby CNB use the mtime at build time or at launch time? I think the timestamp normalisation happens at the end of the build, so if the Ruby CNB uses the mtime only during the build I presume everything should still work?

[schneems]

It uses mtime https://github.com/heroku/buildpacks-ruby/blob/6966b889697edff04935f8e0b28fcb8ad776f7a5/commons/src/cache/clean.rs#L7-L21. But it relies on mtime being correct across multiple builds. I.e. if someone deploys an asset five months ago, I want to evict that from the cache before a file that was just added. I think I should test this validation logic to ensure it works as I expect with a pack build