Repository navigation
test_strftime_y2k fails on embedded Linux #123681
Description
Activity
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.
Reacted by blhsing(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)
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).
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?
If these configure tests are not correct, then other configure tests can be not correct too.
Ha! I knew I should have looked more in detail the logs:
On aarch64-unknown-linux-gnu (failing tests), we have two different configure:
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... yes2024-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 orfull_date != 1900-01-01. So maybe%Fdoes not fail. We can probably debug the tests to check whether it_time.strftimethat bugs, or if it is the configure test that bugs. I don't know if it's possible for_time.strftimeto support%F(which does not directly callstrftime()) but at the same time fail thestrftime(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.
Reacted by blhsing2024-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... yes2024-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_IFELSEmacro at all when cross-compiling, but directly performs action-if-cross-compiling as specified, which I thought should be made ano(to be pessimistic) when it should really be ayesbecause we should make sure to handle%Fand%Courselves when we are unsure if the target platform can handle them.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.
Reacted by blhsingAhh 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!
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).
Reacted by blhsing6 remaining items
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.
it is not on Linux for %C
%Cworks 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%Cspecifier in our test suite. If it did not work on Linux, CI would be broken.>>> time.strftime("%C", (99, 1, 1, 0, 0, 0, 0, 1, 0)) '0'
In C99 it should be 2 digits.
So, we need a test for
normalize_century(ideally at run-time, to avoid cross-compilation issues), but in CPython we can assume%Cand%Fare available, right?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.
As I see it, they're guaranteed in CPython (via the C99 build requirement), but not in Python the language.
- added a commit that references this issue
on Aug 19, 2025 - added a commit that references this issue
on Oct 7, 2025
Bug report
Bug description:
This is an issue to track the progress of fixing the JIT. Branches that trigger the embedded Linux tests fail on
test_strftime_y2k, e.g. https://github.com/python/cpython/actions/runs/10655985897/job/29534232332?pr=123546. As a side-effect this causes users getting notification that their JIT workflow failed.Both the C and F specifiers are failing for this specific test:
Details
A solution is to add this test to the ignored tests or to fix the detection algorithm.
cc @blhsing @serhiy-storchaka
CPython versions tested on:
CPython main branch
Operating systems tested on:
Other
Linked PRs
Related and proposed PR: gh-128106