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