Thank you for the PR Bernhard. Please can you add a test?

I wonder also if we should use SOURCE DATE EPOCH instead, are there any drawbacks to lying to users about the GZip creation time?

cc @jayaddison who has done similar work in core Sphinx.

A

I think, we should avoid the extra logic of handling SOURCE_DATE_EPOCH
This change is equivalent to gzip -n which is the default behaviour since some years for compressing stdin, because there is no point in storing an mtime then. Also, bzip, xz and zstd formats don't have such a mtime header value and the gzip format only supports timestamps until 2106 anyway.

I'd appreciate, if you could add the test. I don't have much experience in python.

When it's not possible to remove timestamps entirely from a build process, I think that SOURCE_DATE_EPOCH is generally the next-preferred alternative; partly because we can't know in advance whether the value is used by subsequent processes (and if it is, retaining the ability to influence the input stream via the environment variable, to detect downstream changes, is useful). What do you think?

Do you have a pointer to some consumer of this file? I cannot imagine why they would use this timestamp.
Overall, I'd prefer to keep it simple, because that is less prone to break.

Ok, thank you @bmwiedemann; no, I'm not aware of any consumers of that timestamp. I'm a Python contributor here but without write access to the repo, and am interested in reproducible builds, so: I propose that I'll open a pull request against your fork soon (within the next few days) to provide the test coverage.

Ok, thank you @bmwiedemann; no, I'm not aware of any consumers of that timestamp. I'm a Python contributor here but without write access to the repo, and am interested in reproducible builds, so: I propose that I'll open a pull request against your fork soon (within the next few days) to provide the test coverage.

This has been opened as bmwiedemann#1 - please run/check the test coverage there (it should fail without the fix in place, and pass once the fix is introduced).

Note: that pull request is opened against the same branch that this pull request originates from -- so merging that one should result in corresponding updates here (including continuous integration checks).

I'm not completely sure what is going on with the mypy linting failure; I wasn't initially able to replicate that locally, but can investigate again at some point in the next few days.

I'm not completely sure what is going on with the mypy linting failure; I wasn't initially able to replicate that locally, but can investigate again at some point in the next few days.

I believe I've discovered the cause of these (unrelated) type-checking errors, and have opened #14 with a possible solution.

Thanks again!