gh-133998: Fix tarfile error on out-of-range mtime in streaming gzip mode

[harjothkhara]

A streaming gzip tarball ("w|gz") with an out-of-range mtime (negative, or a clock past 2106) raises struct.error instead of writing the file.

gzip already clamps these to 0 (GH-134278); this does the same for tarfile's streaming path. The non-streaming w:gz path uses GzipFile, so it was already fine.

Added tests for the boundary and bad-clock cases.

AI-assisted; I reviewed it and can explain it.

• Issue: gzip: cannot create file if mtime > 2106-02-07T06:28:15 #133998

[harjothkhara]

@serhiy-storchaka you flagged the same out-of-range mtime bug in tarfile._init_write_gz on gh-133998 (the gzip half landed in #134278). This PR applies the clamp-to-0 fix there, with tests and a NEWS entry. Can you please take a look when you have time?

[github-actions]

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

[vstinner]

LGTM. Thanks for tests which cover all code paths. The Changelog entry describes well the fix. And tarfile behaves as gzip (same code in fact). So all good!

[vstinner]

Oh, test_os.test_posix failed in the MSan job:

FAIL: test_fexecve (test.test_os.test_posix.PosixTester.test_fexecve)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/runner/work/cpython/cpython/Lib/test/test_os/test_posix.py", line 219, in test_fexecve
    support.wait_process(pid, exitcode=0)
    ~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^
  File "/home/runner/work/cpython/cpython/Lib/test/support/__init__.py", line 2491, in wait_process
    raise AssertionError(f"process {pid} exited with code {exitcode2}, "
                         f"but exit code {exitcode} is expected")
AssertionError: process 21288 exited with code 1, but exit code 0 is expected

MSan logs:

==> /home/runner/work/cpython/cpython/san_log.13546 <==
==13546==WARNING: MemorySanitizer failed to allocate 0x4000000000000021 bytes

==> /home/runner/work/cpython/cpython/san_log.21288 <==
execve failed, errno 2

Does MSan change excve() behavior?

cc @StanFromIreland

[vstinner]

So far, I failed to reproduce the issue on Fedora 44 with clang version 22.1.8.

$ cat Modules/Setup.local
*disabled*
_bz2 _ctypes _curses _curses_panel _dbm _decimal _gdbm _hashlib
_lzma _sqlite3 _ssl _tkinter _uuid _zstd readline zlib

$ ./configure OPT="-O2 -g" --with-memory-sanitizer --with-assertions CC=clang LD=clang
$ make
$ ./python -m test -v test_os.test_posix 

The GHA CI uses CC.version: [clang] Ubuntu clang version 21.1.8 (6ubuntu1) on Ubuntu 26.04.1 LTS (Resolute Raccoon).

[vstinner]

I created #158868 for the MSan failure.