TMR: strftime conversion specifier failed during test

[cocobean]

TEST: Test case covering all the conversion specifiers that are supported in strftime().

Ref: conformance/interfaces/strftime/1-1.c

Expected Result: PASS

Actual Result: FAILED - (one of the tests failed with 'X Bytes 0 - Test Failed: %X doesn't equal a least 8 bytes')

Tested on Haiku hrev56376 x64 with Open POSIX Test Suite 1.5.2

[waddlesplash]

What happens with musl on Linux?

[cocobean]

Update (2022-09-12): MUSL dev confirmed that MUSL passes these strftime tests on Linux.

[cocobean]

Setting LC_TIME=C fixed test 2-1 (i.e. test 2-1 now passes testing fully, but not 1-1 (i.e. test 1-1 still fails one minor test) on hrev56416 x64. I'll direct the issue to MUSL dev. Seems locale support is an open issue on MUSL wiki (​https://wiki.musl-libc.org/open-issues.html):

"Locale limitations

Locale support is very limited, and barely works. Translation of LC_TIME is not possible because the key strings for ABMON_5 and MON_5 (“May”) are identical. Custom collation orders (LC_COLLATE) are not implemented at all, despite there always having been an intent to support them. LC_NUMERIC and LC_MONETARY also admit no variation by locale. Solving these problems requires a major overhaul, but the main missing prerequisite is involvement from users who want the functionality.

Building officially recognized locales for musl is also a recognized open problem. The bulk of the data should be derived mechanically from the Unicode CLDR where possible, but the CLDR seems to lack certain time format variants corresponding to the ones C/POSIX needs for nl_langinfo/strftime. This probably requires a great deal of manual work to remedy, ideally getting the missing formats added upstream with Unicode."

[korli]

Replying to cocobean:

Seems locale support is an open issue on MUSL wiki (​https://wiki.musl-libc.org/open-issues.html):

Not sure why this would apply, given that we use ICU, for instance getShortMonths() and getMonths() to get the month names in a locale.

[davidkaroly]

there seems to be a similar issue with strftime() in wxWidgets (both wxGTK and wxQT variants)

most likely %c, %x, %X are impacted.

[cocobean]

Update: hrev56627 x86, TMR - strftime execution tests PASSED. Please close this ticket.