STINNER Victor <vstin...@python.org> added the comment:
> [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.
----------
Added file: https://bugs.python.org/file48871/mtime.c
_______________________________________
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue39460>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
