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

[ctrlaltf2]

See #134261 for issue background and technical detail on causes. This solves the issue by using gmtime whenever SOURCE_DATE_EPOCH is involved, to prevent pulling in system timezone information when performing time calculations.

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

[python-cla-bot]

All commit authors signed the Contributor License Agreement.

[bedevere-app]

Most changes to Python require a NEWS entry. Add one using the blurb_it web app or the blurb command-line tool.

If this change has little impact on Python users, wait for a maintainer to apply the skip news label instead.

[Wulian233]

I added this feature 8 months ago. There was a reason for using localtime. See #124435 (review) and 54a7116

Maybe we can ask @jaraco

[emmatyping]

@jaraco would you have time to look at this one? Would appreciate your expertise on whether changing to UTC time would be acceptable only for cases where SOURCE_DATE_EPOCH is set.

[github-actions]

This PR is stale because it has been open for 30 days with no activity.

[jaraco]

Here is the conversation where we discussed localtime vs. gmtime.

My concern at the time was that the code was changing localtime(time.time()) to gmtime(time.time()) even for the case where SOURCE_DATE_EPOCH was unset. And at the time, there was no explanation for why that change should be made and it seemed unrelated to the proposed change.

I'm pleased to see that this PR addresses my concern by keeping the behavior unchanged for unset SOURCE_DATE_EPOCH.

Unfortunately, even the tests are merely reflecting the implementation, so aren't capturing an external expectation. We can improve that situation in this PR, at least for the SOURCE_DATE_EPOCH case.

I do think we should apply this proposed change as a bugfix to all relevant Pythons. It seems to me this value was never correct. It will mean some instability, but I'm struggling to think of any other option. Better to have consistent behavior across all patched Pythons than have reproducibility dependent on minor Python version.

It's conceivable that gmtime should also be used unconditionally, but that's a broader problem with greater backward compatibility concerns and would demand larger scrutiny.

[read-the-docs-community]

Documentation build overview

📚 cpython-previews | 🛠️ Build #32763695 | 📁 Comparing 5c09422 against main (409fa8e)

  🔍 Preview build  

481 files changed · ± 448 modified · - 33 deleted

± Modified

• about.html
• bugs.html
• glossary.html
• index.html
• license.html
• py-modindex.html
• c-api/allocation.html
• c-api/apiabiversion.html
• c-api/arg.html
• c-api/buffer.html
• and 438 more...

- Deleted

• improve-page-nojs.html
• improve-page.html
• _static/tachyon-example-flamegraph.html
• _static/tachyon-example-heatmap.html
• c-api/curses.html
• c-api/extension-modules.html
• c-api/interp-lifecycle.html
• c-api/picklebuffer.html
• c-api/profiling.html
• c-api/sentinel.html
• and 23 more...

[jaraco]

CI runners are flaky. I've had to retry the jobs twice, both for unrelated reasons. I expect them to pass soon.

[jaraco]

Sadly the second retry failed in the same Ubuntu job. Sadly, it's a spurious error unrelated to this change. Here's Copilot's analysis:

This job did not fail because of a code or test regression in the PR. It was terminated by the runner infrastructure:

make ci was still running tests when the job was killed with exit code 143
the log ends with: The runner has received a shutdown signal
there is no Python traceback, assertion failure, compiler error, or failing test name before termination

Relevant evidence:

The failing step is the ASAN test job’s final test command in .github/workflows/build.yml:547-548:
    [build.yml#L547-L548](https://github.com/python/cpython/blob/0f962dc8601f31d7b9e1be6745a7cf7c4d5ef94e/.github/workflows/build.yml#L547-L548)
    run: xvfb-run make ci
The job was progressing normally through the test suite when it was interrupted.
make ci is the broad CI target from the top-level Makefile, so the interruption happened during the general test run, not in a specific failing source file.

Solution:

Treat this as a spurious CI failure and rerun the job.
No code change is justified based on these logs alone.
If this becomes repeatable in the same job, reduce susceptibility to runner interruption by narrowing the ASAN test workload rather than changing product code.

If you want a code-level mitigation for repeat occurrences, the best change is in the workflow, not CPython itself. For example, replace the broad ASAN command with a more targeted test invocation in .github/workflows/build.yml:
YAML

• name: Tests
  run: xvfb-run ./python -m test --fast-ci --timeout 1200

or, if ASAN-specific coverage is still desired but runtime needs to be reduced, run a curated subset instead of make ci.

Bottom line: the correct solution for this job is to rerun it; there is no evidence of a bug in the referenced code from this log.

[miss-islington-app]

Thanks @ctrlaltf2 for the PR, and @jaraco for merging it 🌮🎉.. I'm working now to backport this PR to: 3.14, 3.15.
🐍🍒⛏🤖

[bedevere-app]

GH-150137 is a backport of this pull request to the 3.15 branch.

[bedevere-app]

GH-150138 is a backport of this pull request to the 3.14 branch.

[jaraco]

I thought maybe there was a timeout, but that doesn't seem likely, as the second attempt ended after ~15 minutes and the third after ~9 minutes. The fourth attempt (second retry/third attempt of ubuntu freethreading) succeeded. So whatever it is is spurious.