ZipFile tests fail in negative timezone offsets on reproducible build environments

[ctrlaltf2]

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

    	# gh-91279: Set the SOURCE_DATE_EPOCH to a specific timestamp
    	epoch = os.environ.get('SOURCE_DATE_EPOCH')
    	get_time = int(epoch) if epoch else time.time()
    	self.date_time = time.localtime(get_time)[:6]

• 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

Linked PRs

• gh-134261: ZipFile - Don't rely on local time for reproducible builds & tests #134264

[thatch]

@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]

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.