Opened 22 months ago
Last modified 12 months ago
#18471 closed bug
strftime() broken for "c" and "X" specifiers. — at Initial Version
Reported by: | bipolar | Owned by: | nobody |
---|---|---|---|
Priority: | normal | Milestone: | Unscheduled |
Component: | - General | Version: | R1/beta4 |
Keywords: | Cc: | ||
Blocked By: | Blocking: | ||
Platform: | All |
Description
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 it 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 :-/)