#18471 closed bug (invalid)
strftime() broken for "c" and "X" specifiers.
Reported by: | bipolar | Owned by: | nobody |
---|---|---|---|
Priority: | normal | Milestone: | Unscheduled |
Component: | - General | Version: | R1/beta4 |
Keywords: | Cc: | ||
Blocked By: | Blocking: | ||
Platform: | All |
Description (last modified by )
Found while analyzing Python's test suite results for test_strptime.py.
(same results on beta4 and on hrev567104, both 64 bits)
The following minimal code:
import time time_tuple = time.struct_time((1999,3,17,22,44,55,2,76,0)) # Specifiers' list from: # https://pubs.opengroup.org/onlinepubs/9699919799/functions/strptime.html for c in 'aAbBcCdDehHIjmMnprRStTUwWxXyY%': print('Testing "%s": "%s"' % (c, time.strftime('%' + c, time_tuple)))
prints correct values for all specifiers except for "c" and "X", as on Haiku I get:
Testing "c": "" Testing "X": ""
For comparison, on both Win10 and Linux I get:
Testing "c": "Wed Mar 17 22:44:55 1999" Testing "X": "22:44:55"
As far as I can tell, time.strftime()
is basically just calling the system's strftime()
on Haiku/Linux (and wcsftime
on Win).
On the seemingly related #17884 davidkaroly said that wxWidgets was also affected and:
"most likely %c, %x, %X are impacted."
Not sure if he still sees the same there.
Seems to me that nl_strftime()
is not producing correct results for D_T_FMT
(%c) and T_FMT
(%X), but works fine for T_FMT_AMPM
(%r) and D_FMT
(%x).
(That is as far as I can go :-/)
Change History (4)
comment:1 by , 17 months ago
Description: | modified (diff) |
---|
comment:3 by , 17 months ago
Resolution: | → invalid |
---|---|
Status: | new → closed |
comment:4 by , 7 months ago
Updating the test case to:
#include <clocale> #include <ctime> #include <cstdio> #include <cstring> void dotest() { // Python's test data: {1999, 3, 17, 22, 44, 55, 2, 76, 0} struct tm time = {55, 44, 22, 17, 2, 99, 3, 75, 0}; const char specifiers[] = "aAbBcCdDehHIjmMnprRStTUwWxXyY%"; for (int i=0; i < strlen(specifiers); i++) { char fmt[3] = {}; char buffer[80] = {}; sprintf(fmt, "%%%c", specifiers[i]); strftime(buffer, 80, fmt, &time); printf("Testing '%c': '%s'\n", specifiers[i], buffer); } } int main(void) { puts("Testing with default locale:"); dotest(); puts("Testing after: setlocale(LC_TIME, \"es_AR.utf8\")"); setlocale(LC_TIME, "es_AR.utf8"); dotest(); }
Shows an empty value for %c
after setting the locale to es_AR.utf8
(same as talked here and subsequent comments).
So, I guess I might have tested with different locales, and that's why I was getting different results.
%X
specifier looks fine tho, so that might be an issue on our Python's port side.
Re-checking the output of the script above, noticed that "%x" also shows differences:
On Haiku:
Testing "x": "Mar 17, 1999"
On Linux and Win10:
Testing "x": "03/17/99"