Repository navigation
ZipFile tests fail in negative timezone offsets on reproducible build environments #134261
Description
Bug report
Bug description:
Background
- Relates to support reproducible Python builds #73894
- Reproducibility for ZipFile introduced in ZipFile.writestr should respect SOURCE_DATE_EPOCH #91279
- See https://reproducible-builds.org/ and https://reproducible-builds.org/docs/buy-in/ for why this is a good thing to have in general, and https://reproducible-builds.org/docs/source-date-epoch for basic information on SOURCE_DATE_EPOCH specifically.
Bug
If building on a reproducible environment such as NixOS, and your local timezone has a negative UTC offset, a large number of the ZipFile tests fail due to a underflow of the DOS date value:
- Zips by default store file timestamps as a DOS date and a DOS time, They are unsigned and 16-bits wide.
- NixOS sets environment variable SOURCE_DATE_EPOCH to 315532800 (1980-01-01 00:00:00 UTC) to specifically support programs and standards assuming DOS time (stdenv: set SOURCE_DATE_EPOCH to a value python supports NixOS/nixpkgs#89794), of which zip is one.
- In recent ZipFile updates, SOURCE_DATE_EPOCH is read from if it exists. If it exists, it's not taken as UTC and is instead converted to the system's local time:
cpython/Lib/zipfile/__init__.py
Lines 625 to 628 in 8d490b3
- If your local time has a negative UTC offset, this ends up subtracting from the minimum possible DOS date value, which underflows to what would be a negative DOS date.
- In tests, ValueError is raised anytime a file is written to a ZipFile, because the DOS date under reproducible systems is not in the range 0 <= date <= 65535.
CPython versions tested on:
CPython main branch
Operating systems tested on:
Linux
Activity
pythongh-134261: Don't rely on local time for reproducible builds & t…
thatch commented on May 20, 2025
@serhiy-storchaka I agree this is an incremental improvement; I'd kind of rather we use UTC timestamps all the time but that's probably a backwards-compatibility issue.
Related to #123059 (but there's not enough code for me to know if that's a dupe)
emmatyping commented on May 27, 2025
I think this is reasonable to change, but we should definitely document the behavior difference when we handle #123059. If you are using SOURCE_DATE_EPOCH you really want the maximally reproducible value, which is not dependent on the timezone of the local machine.
emmatyping commented on May 2, 2026
Unfortunately, the SOURCE_DATE_EPOCH code shipped in 3.14 so this is probably a behavior change we should warn users about.
gh-134261: ZipFile - Don't rely on local time for reproducible builds…
[3.14] gh-134261: ZipFile - Don't rely on local time for reproducible…
[3.15] gh-134261: ZipFile - Don't rely on local time for reproducible…
emmatyping commented on May 25, 2026
I think we can close this now, as the fix is merged and backported 🎉