Activity

1. picnixz

   added

   type-bugAn unexpected behavior, bug, or errorAn unexpected behavior, bug, or error

   testsTests in the Lib/test dirTests in the Lib/test dir

   on Sep 4, 2024
2. picnixz

   added this to Date and time issues 🕰️on Sep 4, 2024
3. serhiy-storchaka commented on Sep 4, 2024

   

   serhiy-storchaka

   on Sep 4, 2024

   Member

   More actions

   It seems that only tests for the C implementation fail.

   We can try to move the detection from the compile time to the run time, like for Python implementation. But it is a puzzle why it does not work here.

   👍React with 👍1Reacted by blhsing
4. picnixz commented on Sep 4, 2024

   

   picnixz

   on Sep 4, 2024

   Last edited by picnixz

   MemberAuthor

   More actions

   (Forget my comment that I deleted, I looked at the wrong commit).

   I think we can improve the configure.ac detection by including the weird cases. Or maybe the test is broken because of this:

   if _time.strftime('%F', (1900, 1, 1, 0, 0, 0, 0, 1, 0)) == '1900-01-01':
       specifiers += 'FC'

   (Those are the two failing specifiers)
5. brandtbucher commented on Sep 6, 2024

   

   brandtbucher

   on Sep 6, 2024

   Member

   More actions

   This particular test failure could be a bit weird, since this CI job involves cross-compiling Python and then running the test suite under emulation. Not sure if it's a "real" issue, or if we should just skip the test (like we do for others).
6. picnixz commented on Sep 7, 2024

   

   picnixz

   on Sep 7, 2024

   Last edited by picnixz

   MemberAuthor

   More actions

   since this CI job involves cross-compiling Python and then running the test suite under emulation

   Does it mean that the configure tests might not be correct (or inconsistent because they were done using cross-compilation?) If so, we can just outright ignore the test I guess?
7. serhiy-storchaka commented on Sep 7, 2024

   

   serhiy-storchaka

   on Sep 7, 2024

   Member

   More actions

   If these configure tests are not correct, then other configure tests can be not correct too.
8. picnixz commented on Sep 8, 2024

   

   picnixz

   on Sep 8, 2024

   Last edited by picnixz

   MemberAuthor

   More actions

   Ha! I knew I should have looked more in detail the logs:

   On aarch64-unknown-linux-gnu (failing tests), we have two different configure:

   https://github.com/python/cpython/commit/e565b87d9dafe89bf262e3ab46edb9c9c8618b27/checks/29534232332/logs

   2024-09-01T17:33:50.4537429Z checking whether year with century should be normalized for strftime... yes
   2024-09-01T17:33:50.4888417Z checking whether C99-specific strftime specifiers are supported... yes

   2024-09-01T17:35:47.4696152Z checking whether year with century should be normalized for strftime... yes
   2024-09-01T17:35:47.4698164Z checking whether C99-specific strftime specifiers are supported... >> no <<

   So it appears we have different ./configure. I don't know which one is actually being used at runtime in the emulated environment. Now, both '%F' and '%C' are C99-specific (https://en.cppreference.com/w/c/chrono/strftime) so the following

   if _time.strftime('%F', (1900, 1, 1, 0, 0, 0, 0, 1, 0)) == '1900-01-01':
       specifiers += 'FC'

   is perhaps a too broad check. Since specifiers 'F' and 'C' are used, we actually expect to support %F, but this contradicts the fact that "C99-specific strftime specifiers are supported" (at least for the second one which seems the most recent and probably the one being used under the hood). The configure check is:

   if (strftime(full_date, sizeof(full_date), "%F", &date) && !strcmp(full_date, "1900-01-01")) {
       return 0;
   }

   In other words, either strftime(full_date, sizeof(full_date), "%F", &date) fails or full_date != 1900-01-01. So maybe %F does not fail. We can probably debug the tests to check whether it _time.strftime that bugs, or if it is the configure test that bugs. I don't know if it's possible for _time.strftime to support %F (which does not directly call strftime()) but at the same time fail the strftime(full_date, sizeof(full_date), "%F", &date) && !strcmp(full_date, "1900-01-01") test.

   ---

   I'm tired so what I wrote here might be wrong but I'll try to investigate tomorrow.

   ❤️React with ❤️1Reacted by blhsing
9. blhsing

   added a commit that references this issue on Sep 9, 2024

   pythongh-123681: handle c99-specific specifiers when cross-compiling

   7be70ff
10. blhsing commented on Sep 9, 2024

    

    blhsing

    on Sep 9, 2024

    Last edited by blhsing

    Contributor

    More actions

    2024-09-08T16:49:27.5943515Z checking whether year with century should be normalized for strftime... yes
    2024-09-08T16:49:27.6286869Z checking whether C99-specific strftime specifiers are supported... yes

    2024-09-08T16:51:33.7240722Z checking whether year with century should be normalized for strftime... yes
    2024-09-08T16:51:33.7242911Z checking whether C99-specific strftime specifiers are supported... >> no <<

    Ahh how could I have not noticed the second configure in the logs! Was scratching my head over why the detection of C99 support got a yes (in the first configure) but the compiled code ended up not handling C99. It makes total sense now.

    The real problem is simply that autoconf does not run the test for the AC_RUN_IFELSE macro at all when cross-compiling, but directly performs action-if-cross-compiling as specified, which I thought should be made a no (to be pessimistic) when it should really be a yes because we should make sure to handle %F and %C ourselves when we are unsure if the target platform can handle them.
11. picnixz commented on Sep 9, 2024

    

    picnixz

    on Sep 9, 2024

    MemberAuthor

    More actions

    Ahh how could I have not noticed the second configure in the logs!

    Well, isn't it trivial to spot it among 11985 lines 😄? Actually, I found the duplicate configure in the logs by a CTRL+F and... saw that I had two results.

    👍React with 👍1Reacted by blhsing
12. blhsing commented on Sep 9, 2024

    

    blhsing

    on Sep 9, 2024

    Contributor

    More actions

    Ahh how could I have not noticed the second configure in the logs!

    Well, isn't it trivial to spot it among 11985 lines 😄? Actually, I found the duplicate configure in the logs by a CTRL+F and... saw that I had two results.

    I used Ctrl-F too, but the browser limits the search to only what's loaded in the memory, when the output of the second configure is hidden because it is loaded on demand by an AJAX call only if I scroll to it. I should've used the "Search Logs" text box in the page to perform the search for the keyword on the server side instead.

    Thanks again!
13. picnixz commented on Sep 9, 2024

    

    picnixz

    on Sep 9, 2024

    MemberAuthor

    More actions

    I used Ctrl-F too, but the browser limits the search to only what's loaded in the memory, when the output of the second configure is hidden because it is loaded on demand by an AJAX call only if I scroll to it. I should've used the "Search Logs" text box in the page to perform the search for the keyword on the server side instead.

    Actually, the trick is to "view raw logs". You'll get the entire logs without buffering (easier to read IMO).

    👍React with 👍1Reacted by blhsing
14. picnixz commented on Sep 27, 2024

    

    picnixz

    on Sep 27, 2024

    MemberAuthor

    More actions

    FTR: #124466 was merged as a temporary workaround so we need to keep the issue opened even though the job looks successful (it's just that we skip it).

    👍React with 👍1Reacted by Savannah Ostrowski
15. 6 remaining items

    Load more
16. erlend-aasland

    closed this as completedin #128106on Jan 3, 2025
17. serhiy-storchaka

    added a commit that references this issue on Jan 3, 2025

    pythongh-123681: Check the strftime() behavior at runtime instead of …

    ...

    0d17190
18. serhiy-storchaka commented on Jan 3, 2025

    

    serhiy-storchaka

    on Jan 3, 2025

    Member

    More actions

    We still need to fix a check for Py_NORMALIZE_CENTURY which does not work in cross-compiler. It is only possible at run time.

    If we require C99 compliant strftime (it is not on Linux for %C), we need to make the following changes:

    • Remove the runtime check from the Python implementation.
    • Update the documentation (it still refers to C89). Document all C99 codes, including the E and O modifiers.
19. serhiy-storchaka

    reopened this on Jan 3, 2025
20. erlend-aasland commented on Jan 3, 2025

    

    erlend-aasland

    on Jan 3, 2025

    Contributor

    More actions

    it is not on Linux for %C

    %C works swell for me on Debian and Ubuntu. Please specify where it does not work instead of putting out such a broad claim. We also explicitly test the %C specifier in our test suite. If it did not work on Linux, CI would be broken.
21. serhiy-storchaka commented on Jan 3, 2025

    

    serhiy-storchaka

    on Jan 3, 2025

    Member

    More actions

    >>> time.strftime("%C", (99, 1, 1, 0, 0, 0, 0, 1, 0))
    '0'

    In C99 it should be 2 digits.
22. encukou commented on Jun 27, 2025

    

    encukou

    on Jun 27, 2025

    Member

    More actions

    So, we need a test for normalize_century (ideally at run-time, to avoid cross-compilation issues), but in CPython we can assume %C and %F are available, right?
23. serhiy-storchaka commented on Jun 27, 2025

    

    serhiy-storchaka

    on Jun 27, 2025

    Member

    More actions

    They are in C99. https://en.cppreference.com/w/c/chrono/strftime

    It seems that the main reason of adding checks for them (see #122272) is that they are not documented in Python, and therefore their support is not guaranteed. If we guarantee their support, we should also document them and add tests. We can make this a new feature in 3.15 or even in 3.14, but I have doubts about 3.13.
24. encukou commented on Jun 27, 2025

    

    encukou

    on Jun 27, 2025

    Member

    More actions

    As I see it, they're guaranteed in CPython (via the C99 build requirement), but not in Python the language.
25. serhiy-storchaka commented on Jun 29, 2025

    

    serhiy-storchaka

    on Jun 29, 2025

    Member

    More actions

    This is an interesting point of view. Then we can remove the check in the C code (which is CPython specific), but should leave it in the Python code, which can be reused in other implementation. From this point of view, #128444 and #136022 are equivalent.
26. encukou commented on Jul 10, 2025

    

    encukou

    on Jul 10, 2025

    Last edited by encukou

    Member

    More actions

    I think #136022 removing def _supports_c99 is OK.
    The Python code still uses _time.strftime. If other implementations replace _time, they will need to update the Python code as well. There's a test so they don't forget.
27. encukou

    added a commit that references this issue on Aug 19, 2025

    gh-123681: Check NORMALIZE_CENTURY behavior at runtime; require C99 (G…

    ...

    719e5c3
28. miss-islington

    added a commit that references this issue on Aug 19, 2025

    pythongh-123681: Check NORMALIZE_CENTURY behavior at runtime; require…

    ...

    6aa25b9
29. encukou

    added a commit that references this issue on Oct 7, 2025

    [3.14] gh-123681: Check NORMALIZE_CENTURY behavior at runtime; requir…

    ...

    7d9b267
30. encukou

    closed this as completedon Oct 9, 2025