GeezerVison

All commit authors signed the Contributor License Agreement.

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.

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

Maybe we can ask @jaraco

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

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

Documentation build overview

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

  🔍 Preview build  

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

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.

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

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

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

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.