s390x Fedora Rawhide 3.x:
https://buildbot.python.org/all/#/builders/323/builds/6

======================================================================
FAIL: test_add_file_after_2107 (test.test_zipfile.StoredTestsWithSourceFile)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/dje/cpython-buildarea/3.x.edelsohn-fedora-rawhide-z/build/Lib/test/test_zipfile.py", line 620, in test_add_file_after_2107
    self.assertRaises(struct.error, zipfp.write, TESTFN)
AssertionError: error not raised by write

Test added in bpo-34097 by:

commit a2fe1e52eb94c41d9ebce1ab284180d7b1faa2a4
Author: Marcel Plch <gmarcel.plch@gmail.com>
Date:   Thu Aug 2 15:04:52 2018 +0200

    bpo-34097: Add support for zipping files older than 1980-01-01 (GH-8270)
    
    ZipFile can zip files older than 1980-01-01 and newer than 2107-12-31 using
    a new strict_timestamps parameter at the cost of setting the timestamp
    to the limit.

see also the following fix:

commit 7b41dbad78c6b03ca2f98800a92a1977d3946643
Author: Marcel Plch <gmarcel.plch@gmail.com>
Date:   Fri Aug 3 17:59:19 2018 +0200

    bpo-34325: Skip zipfile test for large timestamps when filesystem don't support them. (GH-8656)
    
    When the filesystem doesn't support files with large timestamps,
    skip testing that such files can be zipped.

The failure has been seen on other architectures on Fedora Rawhide when building the Python 3.8.1 package:
https://koji.fedoraproject.org/koji/taskinfo?taskID=40870434

In Fedora, this has started happening after the update of the following packages:

https://koschei.fedoraproject.org/build/7758715

 gcc
10.0.1-0.3.fc32 (in fact, there was gcc 9 in there, the report is maybe broken)
10.0.1-0.4.fc32

 libuuid
2.35-0.5.fc32
2.35-1.fc32

 glibc
2.30.9000-30.fc32
2.30.9000-31.fc32

 libselinux
3.0-1.fc32
3.0-2.fc32

 libblkid
2.35-0.5.fc32
2.35-1.fc32

 libgomp
10.0.1-0.3.fc32
10.0.1-0.4.fc32

 util-linux
2.35-0.5.fc32
2.35-1.fc32

 libmount
2.35-0.5.fc32
2.35-1.fc32

 libsmartcols
2.35-0.5.fc32
2.35-1.fc32

 libfdisk
2.35-0.5.fc32
2.35-1.fc32

I tried but failed to reproduce the issue on Fedora Rawhide x86-64. I built Python from source and run Python from its source tree:

./python -m test -v test_zipfile

Maybe the issue only occurs if Python is installed? Or it depends on the filesystem where the ZIP file is created?

On my Fedora 31, /tmp is mounted as a tmpfs filesystem. Using it explicitly doesn't make the test to fail:

./python -m test -v test_zipfile -m test_add_file_after_2107 --tempdir /tmp

Is currently anybody actively working on this? Please, report what you have found out, if so.
I'd like to start digging into this tomorrow and possibly avoid any duplicit work.

> Is currently anybody actively working on this? Please, report what you have found out, if so. I'd like to start digging into this tomorrow and possibly avoid any duplicit work.

I tried but failed to reproduce the bug on Fedora 31 and Fedora Rawhide.

I tested 3.8 and master development branches on Fedora 31 x86-64 laptop: "./configure --with-pydebug CFLAGS=-O0 && make && ./python -m test -v test_zipfile" pass.

I tested Python 3.9.0a3 on my up-to-date Fedora Rawhide x86-64 VM: "./configure --with-pydebug CFLAGS=-O0 && make && ./python -m test -v test_zipfile" pass. I also tried to install Python in /opt/py39 and run tests using /opt/py39/bin/python3.9: the test still pass.

I also tested Python 3.9.0a3 on an up-to-date Fedora Rawhide ppc64 mock container: Python configured as the Fedora package does (LTO, PGO, CFLAGS, LDFLAGS, etc.). test_zipfile pass as well.

Since I cannot reproduce the issue, nor access a machine which the bug occurs, I don't know how to debug this issue.

Can I get access to "s390x Fedora Rawhide 3.x" buildbot worker?

I didn't try to rebuild Python using the Fedora specfile. I only built Python manually.

$ ./python -m test tet_zipfile
0:00:00 load avg: 0.03 Run tests sequentially
0:00:00 load avg: 0.03 [1/1] tet_zipfile
test tet_zipfile crashed -- Traceback (most recent call last):
  File "/home/dje/src/cpython/Lib/test/libregrtest/runtest.py", line 270, in _runtest_inner
    refleak = _runtest_inner2(ns, test_name)
  File "/home/dje/src/cpython/Lib/test/libregrtest/runtest.py", line 221, in _runtest_inner2
    the_module = importlib.import_module(abstest)
  File "/home/dje/src/cpython/Lib/importlib/__init__.py", line 127, in import_module
    return _bootstrap._gcd_import(name[level:], package, level)
  File "<frozen importlib._bootstrap>", line 1021, in _gcd_import
  File "<frozen importlib._bootstrap>", line 998, in _find_and_load
  File "<frozen importlib._bootstrap>", line 975, in _find_and_load_unlocked
ModuleNotFoundError: No module named 'test.tet_zipfile'

tet_zipfile failed

== Tests result: FAILURE ==

1 test failed:
    tet_zipfile

Total duration: 76 ms
Tests result: FAILURE

Sorry, posted the wrong output above.

$ ./python -m test test_zipfile
0:00:00 load avg: 0.01 Run tests sequentially
0:00:00 load avg: 0.01 [1/1] test_zipfile
test test_zipfile failed -- Traceback (most recent call last):
  File "/home/dje/src/cpython/Lib/test/test_zipfile.py", line 620, in test_add_file_after_2107
    self.assertRaises(struct.error, zipfp.write, TESTFN)
AssertionError: error not raised by write

test_zipfile failed in 55.6 sec

== Tests result: FAILURE ==

1 test failed:
    test_zipfile

Total duration: 55.6 sec
Tests result: FAILURE

Fedora downstream issue: https://bugzilla.redhat.com/show_bug.cgi?id=1795576

Do you believe that a single GCC 10 issue is affecting PPC64LE, ARM, and s390x, but expressed in different manners on the different architectures OR is the PPC64LE issue separate and architecture-depdendent?

I think this happens "randomly" regardless of the architecture. I've seen it on x86_64 as well.

I suspect that the timestamp set by os.utime() is not the one seen by os.stat(). Or maybe time.localtime() behavior changed.

Try attached utime_stat_localtime.py script.

Output on Fedora 31 in my home directory which uses btrfs:

$ python3.7 utime_stat_localtime.py 
os.utime (sec): 4386268800
os.stat (sec): 4386268800
os.stat (ns): 4386268800000000000
stat==utime? True
localtime: (2108, 12, 30, 1, 0, 0)

Output on s390x Fedora Rawhide:
$ ./python utime_stat_localtime.py 
os.utime (sec): 4386268800
os.stat (sec): 4386268800
os.stat (ns): 2147483647000000000
stat==utime? False
localtime: (2038, 1, 18, 22, 14, 7)

> os.stat (sec): 4386268800
> ...
> localtime: (2038, 1, 18, 22, 14, 7)

Aha, localtime() behavior changed for timestamp larger than 2**31. What is the version of the glibc package?

> s390x Fedora Rawhide 3.x:
> https://buildbot.python.org/all/#/builders/323/builds/6

pythoninfo of this build says:

platform.libc_ver: glibc 2.30.9000

(Same in the latest build, build 25.)

--

On AMD64 Fedora Rawhide 3.x with glibc-2.30.9000-31.fc32.x86_64, I get years after 2038:

vstinner@python-builder-rawhide$ ./python
Python 3.9.0a3+ (heads/master:0cd5bff6b7, Jan 28 2020, 19:39:07) 
[GCC 10.0.1 20200123 (Red Hat 10.0.1-0.5)] on linux
Type "help", "copyright", "credits" or "license" for more information.

>>> import time
>>> time.localtime(2**31)
time.struct_time(tm_year=2038, tm_mon=1, tm_mday=18, tm_hour=22, tm_min=14, tm_sec=8, tm_wday=0, tm_yday=18, tm_isdst=0)

>>> time.localtime(2**31-3600*24)
time.struct_time(tm_year=2038, tm_mon=1, tm_mday=17, tm_hour=22, tm_min=14, tm_sec=8, tm_wday=6, tm_yday=17, tm_isdst=0)

>>> time.localtime(2**32)
time.struct_time(tm_year=2106, tm_mon=2, tm_mday=7, tm_hour=1, tm_min=28, tm_sec=16, tm_wday=6, tm_yday=38, tm_isdst=0)

>>> time.localtime(2**33)
time.struct_time(tm_year=2242, tm_mon=3, tm_mday=16, tm_hour=8, tm_min=56, tm_sec=32, tm_wday=2, tm_yday=75, tm_isdst=1)

I don't see anything about localtime() or the year 2038 bug in glibc 2.30 release notes:
https://lwn.net/Articles/795127/

I'm aware of work in the Linux kernel and glibc for the year 2038 bug, but for 32-bit systems:
https://lwn.net/Articles/776435/

> s390x Fedora Rawhide 3.x:
> https://buildbot.python.org/all/#/builders/323/builds/6

I also checked the configure: time_t size is 64-bit on this system, so it should not be impacted on the glibc/Linux kernel work on the year 2038 bug.

Notes on the glibc:

* localtime() calls __tz_convert()
* localtime() and __tz_convert() have been modified recently to support 64-bit timestamp
* __tz_convert() is implemented in time/tzset.c
* localtime() is implemented in time/localtime.c

$ ./python
Python 3.9.0a3+ (heads/master:aabdeb766b, Jan 28 2020, 13:50:48) 
[GCC 10.0.1 20200121 (Red Hat 10.0.1-0.4)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import time
>>> time.localtime(2**31)
time.struct_time(tm_year=2038, tm_mon=1, tm_mday=18, tm_hour=22, tm_min=14, tm_sec=8, tm_wday=0, tm_yday=18, tm_isdst=0)
>>> time.localtime(2**31-3600*24)
time.struct_time(tm_year=2038, tm_mon=1, tm_mday=17, tm_hour=22, tm_min=14, tm_sec=8, tm_wday=6, tm_yday=17, tm_isdst=0)
>>> time.localtime(2**32)
time.struct_time(tm_year=2106, tm_mon=2, tm_mday=7, tm_hour=1, tm_min=28, tm_sec=16, tm_wday=6, tm_yday=38, tm_isdst=0)
>>> time.localtime(2**33)
time.struct_time(tm_year=2242, tm_mon=3, tm_mday=16, tm_hour=8, tm_min=56, tm_sec=32, tm_wday=2, tm_yday=75, tm_isdst=1)

David Edelsohn:

> Output on s390x Fedora Rawhide:
> (...)
> os.stat (sec): 4386268800
> os.stat (ns): 2147483647000000000

Oh wait, ns != sec * 10**9 here. "2147483647" is 2**31-1 (INT_MAX).

It looks like a bug in fill_time() of Modules/posixmodule.c. I suspect a bug in _PyLong_FromTime_t().

On this buildbot worker, we have:

    checking size of long long... 8
    checking size of time_t... 8

So _PyLong_FromTime_t() should be implemented as:

    return PyLong_FromLongLong((long long)t);

_PyLong_FromTime_t() raw value is exported in os.stat() as os.stat(filename)[8].

Attached utime_stat_localtime2.py exposes it:

vstinner@apu$ ./python utime_stat_localtime2.py 
os.utime (sec): 4386268800
os.stat (sec int): 4386268800
os.stat (sec float): 4386268800.0
os.stat (ns): 4386268800000000000

On Fedora 31 x86-64 with GCC 9.2.1, gcc -O3, _PyLong_FromTime_t() really just calls PyLong_FromLongLong():

(gdb) disassemble _PyLong_FromTime_t
Dump of assembler code for function _PyLong_FromTime_t:
   0x0000000000521f30 <+0>:	jmp    0x457800 <PyLong_FromLongLong>

$ ./python utime_stat_localtime2.py 
os.utime (sec): 4386268800
os.stat (sec int): 2147483647
os.stat (sec float): 2147483647.0
os.stat (ns): 2147483647000000000

Not -O3, but it's calling PyLong_FromLongLong on s390x as well

   0x00000000011ca524 <+28>:	brasl	%r14,0x10649b0 <PyLong_FromLongLong>

"""
$ ./python utime_stat_localtime2.py 
os.utime (sec): 4386268800
os.stat (sec int): 2147483647
os.stat (sec float): 2147483647.0
os.stat (ns): 2147483647000000000
"""

It doesn't make sense !? In msg360916, you had:

os.stat (sec): 4386268800 <= os.stat().st_mtime
os.stat (ns): 2147483647000000000 <= os.stat().st_mtime._ns

How is it possible that sometimes st_mtime is right, and sometimes st_mtime is so plain wrong?

--

Test setting mtime in Python, reading mtime using /usr/bin/stat, then reading file stat in Python:

$ touch testfn

$ python3 -c 'import os; os.utime("testfn", (4386268800, 4386268800))'

$ stat testfn 
(...)
Modify: 2108-12-30 01:00:00.000000000 +0100
(...)

$ python3 -c 'import os; st=os.stat("testfn"); print(st); print(tuple(st)); print(st.st_mtime_ns)'

os.stat_result(st_mode=33204, st_ino=24648296, st_dev=40, st_nlink=1, st_uid=1000, st_gid=1000, st_size=0, st_atime=4386268800, st_mtime=4386268800, st_ctime=1580263179)
(33204, 24648296, 40, 1, 1000, 1000, 0, 4386268800, 4386268800, 1580263179)
4386268800000000000

[dje@rawhide ~]$ touch testfn
[dje@rawhide ~]$ python3 -c 'import os; os.utime("testfn", (4386268800, 4386268800))'
[dje@rawhide ~]$ stat testfn
  File: testfn
  Size: 0         	Blocks: 0          IO Block: 4096   regular empty file
Device: fd00h/64768d	Inode: 17887487    Links: 1
Access: (0664/-rw-rw-r--)  Uid: ( 1001/     dje)   Gid: ( 1001/     dje)
Context: unconfined_u:object_r:user_home_t:s0
Access: 2038-01-18 22:14:07.000000000 -0500
Modify: 2038-01-18 22:14:07.000000000 -0500
Change: 2020-01-28 21:19:14.707112199 -0500
 Birth: 2020-01-28 21:19:01.627112199 -0500
[dje@rawhide ~]$ python3 -c 'import os; st=os.stat("testfn"); print(st); print(tuple(st)); print(st.st_mtime_ns)'
os.stat_result(st_mode=33204, st_ino=17887487, st_dev=64768, st_nlink=1, st_uid=1001, st_gid=1001, st_size=0, st_atime=2147483647, st_mtime=2147483647, st_ctime=1580264354)
(33204, 17887487, 64768, 1, 1001, 1001, 0, 2147483647, 2147483647, 1580264354)
2147483647000000000

In utime_stat_localtime.py, "os.stat (sec)" is the result of os.utime.
In utime_stat_localtime2.py "os.stat (sec int)" is the result of os.stat.

> [dje@rawhide ~]$ python3 -c 'import os; os.utime("testfn", (4386268800, 4386268800))'
> [dje@rawhide ~]$ stat testfn
> (...)
> Modify: 2038-01-18 22:14:07.000000000 -0500

Oh. It means that os.utime() replaces mtime=4386268800 with a value close to INT_MAX (2**31-1) to workaround the year 2038 bug.

But the buildbot worker runs Fedora Rawhide and uses the architecture s390x with is a 64-bit system: sizeof(time_t)=8. The glibc is not supposed to change mtime on such platform.

I wrote attached mtime.c which is supposed to reproduce the issue.

Example on my Fedora Rawhide x86-64 VM (glibc-2.30.9000-31.fc32.x86_64):
---
$ gcc mtime.c -o mtime && ./mtime
uname -a:
Linux rawhide 5.5.0-0.rc6.git3.1.fc32.x86_64 #1 SMP Fri Jan 17 18:29:51 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
sizeof(time_t) = 8 bytes
sizeof(void*) = 8 bytes

open(testfn, O_WRONLY | O_CREAT)
utimensat(AT_FDCWD, testfn, {atime=mtime=4386268800.0}, 0)
stat(testfn)
st.st_mtime = 4386268800
st.st_mtim.tv_nsec = 0
(ignored: st.st_mtime.tv_sec = 0)
unlink(testfn)
---

I get "st.st_mtime = 4386268800" as expected.

I'm now curious which syscalls are used by the glibc to implement utimensat() and stat().

On a ppc64le Fedora Rawhide running Linux kernel 5.4.8-200.fc31.ppc64le with glibc 2.30.9000, I get:

$ sudo dnf install -y strace # if neeeded
$ strace -o trace ./mtime
(...)

$ grep -E '^(utime|stat)' trace 
utimensat(AT_FDCWD, "testfn", [{tv_sec=4386268800, tv_nsec=0} /* 2108-12-30T00:00:00+0000 */, {tv_sec=4386268800, tv_nsec=0} /* 2108-12-30T00:00:00+0000 */], 0) = 0
stat("testfn", {st_mode=S_IFREG|000, st_size=0, ...}) = 0

=> the glibc uses utimensat() and stat() syscalls.

I get the same syscalls on a x64-64 Fedora Rawhide (Linux kernel 5.5.0-0.rc6.git3.1.fc32.x86_64, libc 2.30.9000):

$ grep -E '^(utime|stat)' trace 
utimensat(AT_FDCWD, "testfn", [{tv_sec=4386268800, tv_nsec=0} /* 2108-12-30T01:00:00+0100 */, {tv_sec=4386268800, tv_nsec=0} /* 2108-12-30T01:00:00+0100 */], 0) = 0
stat("testfn", {st_mode=S_IFREG|000, st_size=0, ...}) = 0

Note: I use "uname -r" to get the Linux kernel version and I run directly "/lib64/libc.so.6" to get the glibc version.

glibc commit adding support for utimensat_time64() syscall:
https://sourceware.org/git/?p=glibc.git;a=commit;h=f5b6fd258b6dd520403a20024e58cb491aca4cbd

See also: https://sourceware.org/glibc/wiki/Y2038ProofnessDesign

I failed to reproduce the issue on s390x Fedora Rawhide, Linux kernel 5.5.0-0.rc4.git2.1.fc32.s390x, glibc-2.30.9000-31.fc32.s390x.

I tested filesystem nfs and tmpfs.

test_add_file_after_2107() pass.

[vstinner@devel10 ~]$ uname -r
5.5.0-0.rc4.git2.1.fc32.s390x

[vstinner@devel10 ~]$ rpm -q glibc
glibc-2.30.9000-31.fc32.s390x

[vstinner@devel10 ~]$ strace -o trace ./mtime
uname -a:
Linux devel10.s390.bos.redhat.com 5.5.0-0.rc4.git2.1.fc32.s390x #1 SMP Fri Jan 3 20:19:26 UTC 2020 s390x s390x s390x GNU/Linux
sizeof(time_t) = 8 bytes
sizeof(void*) = 8 bytes

open(testfn, O_WRONLY | O_CREAT)
utimensat(AT_FDCWD, testfn, {atime=mtime=4386268800.0}, 0)
stat(testfn)
st.st_mtime = 4386268800
st.st_mtim.tv_nsec = 0
(ignored: st.st_mtime.tv_sec = 0)
unlink(testfn)

[vstinner@devel10 ~]$ grep -E '^(utime|stat)' trace 
utimensat(AT_FDCWD, "testfn", [{tv_sec=4386268800, tv_nsec=0} /* 2108-12-29T19:00:00-0500 */, {tv_sec=4386268800, tv_nsec=0} /* 2108-12-29T19:00:00-0500 */], 0) = 0
stat("testfn", {st_mode=S_IFREG|041, st_size=0, ...}) = 0

> I failed to reproduce the issue on s390x Fedora Rawhide, Linux kernel 5.5.0-0.rc4.git2.1.fc32.s390x, glibc-2.30.9000-31.fc32.s390x.

I still cannot reproduce after a "dnf upgrade -y":

* Linux 5.5.0-0.rc6.git3.1.fc32.s390x
* glibc-2.30.9000-31.fc32.s390x

I tested attached mtime.c and Python test_add_file_after_2107() on nfs and tmpfs filesystems.

The s390x Fedora Rawhide 3.x buildbot worker where the bug occurs uses the same Linux kernel (5.5.0-0.rc6.git3.1.fc32.s390x) and it looks like the same glibc version (glibc 2.30.9000). Checking "rpm -q glibc" would say if it's exactly the same Fedora package.

David: what is the GCC version? (rpm -q gcc)

Summary:

* test_zipfile.test_add_file_after_2107() fails on Fedora Rawhide 3.x
* Bug seen on Python 3.8 and Python 3.9
* Bug seen on s390x and x86-64 architectures
* It seems like the bug occurs in os.utime() with atime=mtime=4386268800 => stat returns mtime=2147483647
* It may be a recent change in the glibc to workaround year 2038 bug

Failure on x86-64 Fedora Rawhide, on Fedora Koji build server:

* https://koji.fedoraproject.org/koji/taskinfo?taskID=40870460
* Linux 5.4.8-200.fc31.x86_64
* glibc 2.30.9000
* gcc (GCC) 10.0.1 20200121 (Red Hat 10.0.1-0.4)
* utimensat() available

Failure on "s390x Fedora Rawhide 3.x" buildbot worker:

* https://buildbot.python.org/all/#/builders/323/builds/27
* Linux 5.5.0-0.rc6.git3.1.fc32.s390x
* glibc 2.30.9000
* gcc (GCC) 10.0.1 20200121 (Red Hat 10.0.1-0.4)
* utimensat() available

Next question: does the issue come from the glibc or the filesystem? Attached mtime.c should ease debug. If you reproduce the issue, please test different filesystem and report which filesystems you tested.

To detect the filesystem used by a directory, I'm using df to find the mount point (ex: "/home") and then mount to get the filesystem:

$ df .
Filesystem      Size  Used Avail Use% Mounted on
/dev/nvme0n1p3  461G  368G   93G  80% /home

$ mount|grep /home
/dev/nvme0n1p3 on /home type btrfs (rw,relatime,seclabel,ssd,space_cache,subvolid=258,subvol=/home)

=> btrfs here

I failed to reproduce the bug on 3 machines.

My x86-64 Fedora VM:

* Linux 5.5.0-0.rc6.git3.1.fc32.x86_64
* glibc-2.30.9000-31.fc32.x86_64
* gcc-10.0.1-0.5.fc32.x86_64
* utimensat() available
* I tested ext4 (/home) and tmpfs (/tmp)

ppc64le mock:

* Linux 5.4.8-200.fc31.ppc64le (kernel of the Fedora 31 host)
* glibc-2.30.9000-31.fc32.ppc64le
* gcc-10.0.1-0.5.fc32.ppc64le
* I tested ext4 (/home) and tmpfs (/tmp)

s390x devel machine:

* Linux 5.5.0-0.rc6.git3.1.fc32.s390x
* glibc-2.30.9000-31.fc32.s390x
* gcc-10.0.1-0.5.fc32.s390x
* I tested nfs4 (/home) and tmpfs (/tmp)

I believe you might be observing an XFS limitation in combination with a Linux VFS bug.

On disk, XFS only supports 32-bit timestamps:

typedef struct xfs_timestamp {
	__be32		t_sec;		/* timestamp seconds */
	__be32		t_nsec;		/* timestamp nanoseconds */
} xfs_timestamp_t;

This is on the roadmap being fixed.

However, the Linux VFS code does not appear to know about this. It caches the full 64-bit value. You only see the truncated value if it is read back from disk:

# touch -t 222201020304 /tmp/t
# ls -l /tmp/t
-rw-r--r--. 1 root root 0 Jan  2  2222 /tmp/t
# echo 3 > /proc/sys/vm/drop_caches 
# ls -l /tmp/t
-rw-r--r--. 1 root root 0 Oct 19  1949 /tmp/t

This is a bug in the Linux VFS layer.

I managed to reproduce the issue on Fedora 31 on a XFS filesystem:

$ touch testfn
$ strace -o trace python3 -c 'import os; os.utime("testfn", (4386268800, 4386268800))'
$ grep ^utimensat trace
utimensat(AT_FDCWD, "testfn", [{tv_sec=4386268800, tv_nsec=0} /* 2108-12-30T01:00:00+0100 */, {tv_sec=4386268800, tv_nsec=0} /* 2108-12-30T01:00:00+0100 */], 0) = 0
$ stat testfn
(...)
Modify: 2038-01-19 04:14:07.000000000 +0100
(...)

It looks like a Linux kernel issue in the XFS filesystem: I don't think that mtime should be *silently* truncated to 2147483647.

The kernel bug is now tracked at https://bugzilla.redhat.com/show_bug.cgi?id=1795576

I wrote PR 18247 to skip the test.

I suggest to leave this issue is open until the kernel is fixed: until the test is no longer skipped.

New changeset 3cb49b62e61208efcefbc04414e769fc173f205d by Victor Stinner in branch 'master':
bpo-39460: Fix test_zipfile.test_add_file_after_2107() (GH-18247)
https://github.com/python/cpython/commit/3cb49b62e61208efcefbc04414e769fc173f205d

New changeset 2b675f0c8fd96f61977f6dc636f44fbd5587b6b3 by Miss Islington (bot) in branch '3.8':
bpo-39460: Fix test_zipfile.test_add_file_after_2107() (GH-18247)
https://github.com/python/cpython/commit/2b675f0c8fd96f61977f6dc636f44fbd5587b6b3

It seems like AIX also has a kernel issue with timestamp after year 2038. The year 2107 is stored as year 1972.

test_add_file_after_2107 (test.test_zipfile.StoredTestsWithSourceFile) ... skipped 'Linux VFS/XFS kernel bug detected: mtime_ns=91301504000000000'

https://bugs.python.org/issue39502#msg361116

>>> print(datetime.datetime.fromtimestamp(91301504))
1972-11-22 18:31:44

--

The test is now skipped if the kernel or filesystem stores incorrectly the timestamp 4386268800 (2108-12-30). I don't think that we can do much more.

On the Linux kernel side, we reported the issue to:
https://bugzilla.redhat.com/show_bug.cgi?id=1795576

I close this issue.