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]

Basically, with the default locale settings.

1. Haiku hrev55181+67 x64: PASSED all three strftime POSIX tests. (TZ/GLIBC)
2. Haiku hrev56417 x64: FAILED test 1-1 and 2-1 strftime POSIX tests. (MUSL)

On Haiku hrev56417 x64, setting LC_TIME=C fixed POSIX 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"

[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.