ZipFile tests fail in negative timezone offsets on reproducible build environments

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

pythongh-134261: Don't rely on local time for reproducible builds & t…

@serhiy-storchaka

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

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.

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…

I think we can close this now, as the fix is merged and backported 🎉

Navigation Menu

Repository navigation

ZipFile tests fail in negative timezone offsets on reproducible build environments #134261

Bug report

Bug description:

Background

Bug

CPython versions tested on:

Operating systems tested on:

Linked PRs

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

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

ZipFile tests fail in negative timezone offsets on reproducible build environments #134261

Description

Bug report

Bug description:

Background

Bug

CPython versions tested on:

Operating systems tested on:

Linked PRs

Activity

thatch commented on May 20, 2025

emmatyping commented on May 27, 2025

emmatyping commented on May 2, 2026

emmatyping commented on May 25, 2026

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions