gh-91279: ZipFile.writestr now respect SOURCE_DATE_EPOCH

[Wulian233]

No SOURCE_DATE_EPOCH environment variable makes pip installing a package generate non-reproducible build artifacts.

SOURCE_DATE_EPOCH is a standardised environment variable that distributions can set centrally and have build tools consume this in order to produce reproducible output. In practice, specifies the last modification of something, usually the source code, measured in the number seconds since the Unix epoch, ie. .SOURCE_DATE_EPOCHJanuary 1st 1970, 00:00:00 UTC

See https://reproducible-builds.org/docs/source-date-epoch/
details in issue: #91279

• Issue: ZipFile.writestr should respect SOURCE_DATE_EPOCH #91279

[ghost]

All commit authors signed the Contributor License Agreement.

[ZeroIntensity]

Could you add a test for this?

[Wulian233]

Could you add a test for this?

Yes, this change should also be synchronized in the tests.

Note: zipfile.writestr is not a function, it is the zipfile.ZipFile.writestr method

https://github.com/python/cpython/blob/main/Lib/test/test_zipfile/_path/test_path.py#L668-L668

[ZeroIntensity]

Oh! TIL

[ZeroIntensity]

LGTM.

[bedevere-app]

A Python core developer has requested some changes be made to your pull request before we can consider merging it. If you could please address their requests along with any other requests in other reviews from core developers that would be appreciated.

Once you have made the requested changes, please leave a comment on this pull request containing the phrase I have made the requested changes; please review again. I will then notify any core developers who have left a review that you're ready for them to take another look at this pull request.

[Wulian233]

I have made the requested changes; please review again

[bedevere-app]

Thanks for making the requested changes!

@jaraco: please review the changes made to this pull request.

[jaraco]

I'm a little uneasy that time.localtime() is now replaced by time.gmtime(). That means that the value will change depending on the local time zone of the machine running the code, which may not be adequately exercised in the code. Are there existing tests that validate that gmtime is the correct usage here?

[Wulian233]

I checked the documentation. Should time.gmtime return UTC time and not change with time zones? time.localtime says "Like gmtime() but converts to local time"

https://docs.python.org/3.14/library/time.html#time.gmtime

[jaraco]

What I mean is that this change alters the behavior for all cases. The issue doesn't make mention of gmtime and only mentions localtime in relation to the current implementation. What's the motivation for changing it?

[Wulian233]

Sorry, I see that I was mistaken. To implement this PR I originally thought it was necessary to change it to gmtime, but in fact, this modification should not have been made😥

[bedevere-app]

A Python core developer has requested some changes be made to your pull request before we can consider merging it. If you could please address their requests along with any other requests in other reviews from core developers that would be appreciated.

Once you have made the requested changes, please leave a comment on this pull request containing the phrase I have made the requested changes; please review again. I will then notify any core developers who have left a review that you're ready for them to take another look at this pull request.

[Wulian233]

I have made the requested changes; please review again

Sorry again for the inconvenience

[bedevere-app]

Thanks for making the requested changes!

@jaraco: please review the changes made to this pull request.