BUG: respect mtime=0 in WheelFile.timestamp for reproducible builds

[BlackHat-Dot]

In WheelFile.timestamp(), 'mtime or time.time()' evaluated 0 as falsy, overriding timestamps set to 0 (such as in reproducible build environments or git archives) with current system time instead of clamping to MIN_TIMESTAMP (1980-01-01 00:00:00 UTC).

Use 'time.time() if mtime is None else mtime' and avoid evaluating time.time() when SOURCE_DATE_EPOCH is provided in the environment.

[dnicolodi]

timestamps set to 0 (such as in reproducible build environments or git archives)

AFAIK, git archives never use a timestamp of 0. I don't know any reproducible build environment that sets file modification times to 1970-01-01. I am curious about where you encountered mtimes set to 0 in a real use case.

[eli-schwartz]

Mtimes of zero sound rather frightening to me. The implication is that it's always older than anything else on your system, which is counterproductive. You should clamp it to something like "the timestamp of the git commit/tag" (git archive automatically does this for you) or "the timestamp that the build was initiated, and then record the SOURCE_DATE_EPOCH used, as per the reproducible-builds spec. Both of these approaches solve the issue of unreproducible variance depending on timing of file extraction/copying, while also preserving genuinely meaningful information such as comparison of release tag dates.

[dnicolodi]

As weird as it is, I do not see reason not to do the right thing when files have modification time set to 0. I cleaned up the patch and the tests.

[dnicolodi]

Thanks @BlackHat-Dot!

[eli-schwartz]

As weird as it is, I do not see reason not to do the right thing when files have modification time set to 0. I cleaned up the patch and the tests.

Yes, I quite agree (modulo code golf in the original iteration of the PR). Handling malformed inputs sanely is important.

But it is a malformed input. :P People should endeavor to not pass it, if possible.