Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

bpo-39502: Fix 64-bit Python PyTime_localtime() on AIX #18285

Open
wants to merge 4 commits into
base: master
from

Conversation

@aixtools
Copy link
Contributor

aixtools commented Jan 30, 2020

so that only 32-bit is range tested for overflow

https://bugs.python.org/issue39502

@@ -0,0 +1,2 @@
Fix PyTime_localtime() on AIX so that only 32-bit is range tested for overflow.

This comment has been minimized.

Copy link
@vstinner

vstinner Jan 30, 2020

Member

I prefer to mention time.localtime() which is seen by users, than mention a private C function. 32-bit overflow is also obscure. I propose:

Fix :func:`time.localtime` on 64-bit AIX  to support years before 1902 and after 2038.
Patch by M Felt.
Python/pytime.c Outdated Show resolved Hide resolved
@pganssle

This comment has been minimized.

Copy link
Member

pganssle commented Jan 30, 2020

@aixtools Can you add a test for this? Does it fix a test that is currently broken on the AIX buildbot or skipped in the test suite?

Edit: Looks like #18282 skipped this particular test, I guess you can remove the skip directive that was added there.

@vstinner

This comment has been minimized.

Copy link
Member

vstinner commented Jan 30, 2020

Edit: Looks like #18282 skipped this particular test, I guess you can remove the skip directive that was added there.

This PR is only for 64-bit AIX. The skip is still useful for 32-bit AIX which is still limited to year 2038: see https://bugs.python.org/issue39502

@aixtools

This comment has been minimized.

Copy link
Contributor Author

aixtools commented Jan 31, 2020

Edit: Looks like #18282 skipped this particular test, I guess you can remove the skip directive that was added there.

This PR is only for 64-bit AIX. The skip is still useful for 32-bit AIX which is still limited to year 2038: see https://bugs.python.org/issue39502

Not sure what to do. Apparently when I did my refresh - it was before #18282 was in master.

I see:

  +612      def test_add_file_after_2107(self):
  +613          # Set atime and mtime to 2108-12-30
  +614          try:
  +615              os.utime(TESTFN, (4386268800, 4386268800))
  +616          except OverflowError:
  +617              self.skipTest('Host fs cannot set timestamp to required value.')
  +618
  +619          mtime_ns = os.stat(TESTFN).st_mtime_ns
  +620          if mtime_ns != (4386268800 * 10**9):
  +621              # XFS filesystem is limited to 32-bit timestamp, but the syscall
  +622              # didn't fail. Moreover, there is a VFS bug which returns
  +623              # a cached timestamp which is different than the value on disk.
  +624              #
  +625              # Test st_mtime_ns rather than st_mtime to avoid rounding issues.
  +626              #
  +627              # https://bugzilla.redhat.com/show_bug.cgi?id=1795576
  +628              # https://bugs.python.org/issue39460#msg360952
  +629              self.skipTest(f"Linux VFS/XFS kernel bug detected: {mtime_ns=}")
  +630
  +631          with zipfile.ZipFile(TESTFN2, "w") as zipfp:
  +632              self.assertRaises(struct.error, zipfp.write, TESTFN)
  +633
  +634          with zipfile.ZipFile(TESTFN2, "w", strict_timestamps=False) as zipfp:
  +635              zipfp.write(TESTFN)
  +636              zinfo = zipfp.getinfo(TESTFN)
  +637              self.assertEqual(zinfo.date_time, (2107, 12, 31, 23, 59, 59))
  +638

And when I run the test I see:

root@x065:[/data/prj/python/python3-3.9]./python -m test -v test_time test_zipfile | grep add_file
test_add_file_after_2107 (test.test_zipfile.StoredTestsWithSourceFile) ... skipped 'Linux VFS/XFS kernel bug detected: mtime_ns=91301504000000000'
test_add_file_before_1980 (test.test_zipfile.StoredTestsWithSourceFile) ... ok

So, I can try something tricky for me (rebase to include #18282), or, leave it asis, or maybe #18282 is removed.

Let me know how you would like (me) to proceed.

p.s. Seems JFS2 could be added -- although, I am testing on NFSv3, and it may be something caused by the NFS server (which is Linux based). I'll try copying the whole thing to a local drive and see what happens.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
5 participants
You can’t perform that action at this time.