Skip to content

Python 3.13.1 test_datetime failures #129483

Description

@karel1980

Bug report

Bug description:

Hi. I'm trying to build from source on a raspberry pi, on a fresh and fully updated debian bookworm install.

test_datetime was failing so I tried to get more information using make test TESTOPTS="-v test_datetime" as suggested by the readme, but that just runs all tests again without additional output for test_datetime (see terminal output pastedbelow.

I hope that's enough information. I'll try to look a bit further, this is just where I got the feeling it might not be 100% my own fault anymore ;)

karel@homeassistant:~/Python-3.13.0 $ lsb_release  -a
No LSB modules are available.
Distributor ID:	Debian
Description:	Debian GNU/Linux 12 (bookworm)
Release:	12
Codename:	bookworm
karel@homeassistant:~/Python-3.13.0 $ uname -a
Linux homeassistant 6.6.51+rpt-rpi-2712 #1 SMP PREEMPT Debian 1:6.6.51-1+rpt3 (2024-10-08) aarch64 GNU/Linux

Test output

karel@homeassistant:~/Python-3.13.1 $ make test TESTOPTS="-v test_datetime"
Running code to generate profile data (this can take a while):
# First, we need to create a clean build with profile generation
# enabled.
make profile-gen-stamp
make[1]: Entering directory '/home/karel/Python-3.13.1'
make[1]: 'profile-gen-stamp' is up to date.
make[1]: Leaving directory '/home/karel/Python-3.13.1'
# Next, run the profile task to generate the profile information.
./python -m test --pgo --timeout=
Using random seed: 1333715147
0:00:00 load avg: 0.33 Run 44 tests sequentially in a single process
0:00:00 load avg: 0.33 [ 1/44] test_array
0:00:02 load avg: 0.38 [ 2/44] test_base64
0:00:02 load avg: 0.38 [ 3/44] test_binascii
0:00:02 load avg: 0.38 [ 4/44] test_binop
0:00:02 load avg: 0.38 [ 5/44] test_bisect
0:00:03 load avg: 0.38 [ 6/44] test_bytes
0:00:08 load avg: 0.43 [ 7/44] test_bz2
0:00:09 load avg: 0.43 [ 8/44] test_cmath
0:00:10 load avg: 0.43 [ 9/44] test_codecs
0:00:11 load avg: 0.48 [10/44] test_collections
0:00:13 load avg: 0.48 [11/44] test_complex
0:00:14 load avg: 0.48 [12/44] test_dataclasses
0:00:15 load avg: 0.48 [13/44] test_datetime
test test_datetime failed
0:00:20 load avg: 0.52 [14/44] test_decimal -- test_datetime failed (4 failures)
0:00:26 load avg: 0.67 [15/44] test_difflib
0:00:27 load avg: 0.67 [16/44] test_embed
0:00:38 load avg: 0.72 [17/44] test_float
0:00:38 load avg: 0.72 [18/44] test_fstring
0:00:42 load avg: 0.74 [19/44] test_functools
0:00:43 load avg: 0.74 [20/44] test_generators
0:00:43 load avg: 0.74 [21/44] test_hashlib
0:00:44 load avg: 0.74 [22/44] test_heapq
0:00:45 load avg: 0.74 [23/44] test_int
0:00:46 load avg: 0.76 [24/44] test_itertools
0:00:53 load avg: 0.78 [25/44] test_json
... rest omitted...

CPython versions tested on:

3.13

Operating systems tested on:

Linux

Linked PRs

Activity

  1. karel1980 commented on Jan 30, 2025

    @karel1980
    Author

    I ended up running ./python -mtest -v test_datetime and got the results listed below.
    Looks like the test_vilnius_1949_* tests fail with something date formatting related. I suspect I have to configure a locale somewhere. I'll keep looking

    
    ======================================================================
    FAIL: test_vilnius_1941_fromutc (test.datetimetester.TestLocalTimeDisambiguation_Pure.test_vilnius_1941_fromutc)
    ----------------------------------------------------------------------
    Traceback (most recent call last):
      File "/home/karel/Python-3.13.1/Lib/test/datetimetester.py", line 5808, in test_vilnius_1941_fromutc
        self.assertEqual(ldt.strftime("%c %Z%z"),
        ~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^
                         'Mon Jun 23 23:59:59 1941 MSK+0300')
                         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    AssertionError: 'Mon 23 Jun 1941 23:59:59 CET MSK+0300' != 'Mon Jun 23 23:59:59 1941 MSK+0300'
    - Mon 23 Jun 1941 23:59:59 CET MSK+0300
    ?     ---    ^^^^          ^^^
    + Mon Jun 23 23:59:59 1941 MSK+0300
    ?         ^^          ^^^^
    
    
    ======================================================================
    FAIL: test_vilnius_1941_toutc (test.datetimetester.TestLocalTimeDisambiguation_Pure.test_vilnius_1941_toutc)
    ----------------------------------------------------------------------
    Traceback (most recent call last):
      File "/home/karel/Python-3.13.1/Lib/test/datetimetester.py", line 5832, in test_vilnius_1941_toutc
        self.assertEqual(gdt.strftime("%c %Z"),
        ~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^
                         'Mon Jun 23 19:59:59 1941 UTC')
                         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    AssertionError: 'Mon 23 Jun 1941 19:59:59  UTC' != 'Mon Jun 23 19:59:59 1941 UTC'
    - Mon 23 Jun 1941 19:59:59  UTC
    ?     ---    ^^^^
    + Mon Jun 23 19:59:59 1941 UTC
    ?         ^^          ++++
    
    
    ======================================================================
    FAIL: test_vilnius_1941_fromutc (test.datetimetester.TestLocalTimeDisambiguation_Fast.test_vilnius_1941_fromutc)
    ----------------------------------------------------------------------
    Traceback (most recent call last):
      File "/home/karel/Python-3.13.1/Lib/test/datetimetester.py", line 5808, in test_vilnius_1941_fromutc
        self.assertEqual(ldt.strftime("%c %Z%z"),
        ~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^
                         'Mon Jun 23 23:59:59 1941 MSK+0300')
                         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    AssertionError: 'Mon 23 Jun 1941 23:59:59 CET MSK+0300' != 'Mon Jun 23 23:59:59 1941 MSK+0300'
    - Mon 23 Jun 1941 23:59:59 CET MSK+0300
    ?     ---    ^^^^          ^^^
    + Mon Jun 23 23:59:59 1941 MSK+0300
    ?         ^^          ^^^^
    
    
    ======================================================================
    FAIL: test_vilnius_1941_toutc (test.datetimetester.TestLocalTimeDisambiguation_Fast.test_vilnius_1941_toutc)
    ----------------------------------------------------------------------
    Traceback (most recent call last):
      File "/home/karel/Python-3.13.1/Lib/test/datetimetester.py", line 5832, in test_vilnius_1941_toutc
        self.assertEqual(gdt.strftime("%c %Z"),
        ~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^
                         'Mon Jun 23 19:59:59 1941 UTC')
                         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    AssertionError: 'Mon 23 Jun 1941 19:59:59  UTC' != 'Mon Jun 23 19:59:59 1941 UTC'
    - Mon 23 Jun 1941 19:59:59  UTC
    ?     ---    ^^^^
    + Mon Jun 23 19:59:59 1941 UTC
    ?         ^^          ++++
    
    
    ----------------------------------------------------------------------
    Ran 1036 tests in 4.967s
    
    FAILED (failures=4, skipped=31)
    test test_datetime failed
    test_datetime failed (4 failures)
    
    == Tests result: FAILURE ==
    
    1 test failed:
        test_datetime
    
    Total duration: 5.1 sec
    Total tests: run=1,036 failures=4 skipped=31
    Total test files: run=1/1 failed=1
    Result: FAILURE
    karel@homeassistant:~/Python-3.13.1 $ 
    
  2. karel1980 commented on Jan 30, 2025

    @karel1980
    Author

    Fixed by setting my locale to 'C'. It was set to en_GB.UTF-8
    Command used to fix it: export LC_ALL=C

    I feel like either I missed an instruction or it would be an improvement to the documentation if it's not there.
    Let me know and I'll send a PR to add it to README.rst (or somewhere else if you prefer somewhere else)

  3. gkirchou commented on Dec 2, 2025

    @gkirchou
    Contributor

    Hit this issue today.

    I am not sure if we should fix this under Makefile while I think we can program this with locale (and it's more reasonable to do this way unless we expect LC_ALL=C to always be the case). Added a PR.

  4. vstinner commented on Dec 2, 2025

    @vstinner
    Member

    I cannot reproduce this issue on Fedora 43:

    $ LC_ALL=en_GB.UTF-8 make test TESTOPTS="-v test_datetime"
    (...)
    Result: SUCCESS
    

    pythoninfo:

    $ ./python -m test.pythoninfo|grep -E 'libc|CC.version|uname|platform\.|os.environ'
    CC.version: gcc (GCC) 15.2.1 20251111 (Red Hat 15.2.1-4)
    
    os.environ[DISPLAY]: :0
    os.environ[HOME]: /home/vstinner
    os.environ[LANG]: fr_FR.UTF-8
    os.environ[MAKEFLAGS]: -j14
    os.environ[PATH]: /home/vstinner/.local/bin:/usr/local/bin:/usr/bin:/home/vstinner/.npm-global/bin
    os.environ[SHELL]: /bin/bash
    os.environ[TERM]: xterm-256color
    os.environ[WAYLAND_DISPLAY]: wayland-0
    
    os.uname: posix.uname_result(sysname='Linux', nodename='mona', release='6.17.7-300.fc43.x86_64', version='#1 SMP PREEMPT_DYNAMIC Sun Nov  2 15:30:09 UTC 2025', machine='x86_64')
    
    platform.architecture: 64bit ELF
    platform.freedesktop_os_release[ID]: fedora
    platform.freedesktop_os_release[NAME]: Fedora Linux
    platform.freedesktop_os_release[VARIANT_ID]: workstation
    platform.freedesktop_os_release[VERSION]: 43 (Workstation Edition)
    platform.freedesktop_os_release[VERSION_ID]: 43
    platform.libc_ver: glibc 2.42
    platform.platform: Linux-6.17.7-300.fc43.x86_64-x86_64-with-glibc2.42
    platform.python_implementation: CPython
    
  5. gkirchou commented on Dec 3, 2025

    @gkirchou
    Contributor

    My environment's LC_ALL is default to unset.

    kirchou@kirchou:~$ echo $LC_ALL
    
    

    Based on Victor's comment, maybe LC_ALL=C is not the only one to solve this?

    If that's the case, my first commit may not be the most accurate fix (depends on the original intention of the test)...

    I changed this by explicitly changing %c to the exact expected time format.

  6. added a commit that references this issue on Dec 4, 2025
  7. added 2 commits that reference this issue on Dec 4, 2025
  8. vstinner commented on Dec 4, 2025

    @vstinner
    Member

    Thanks for the bug report, it has been fixed. In the meanwhile, you can use the C locale (ex: LC_ALL=C).

  9. added 2 commits that reference this issue on Dec 4, 2025
  10. added a commit that references this issue on Dec 6, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    testsTests in the Lib/test dirtype-bugAn unexpected behavior, bug, or error

    Projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions