#17884 closed bug (fixed)

TMR: strftime conversion specifier failed during test

Reported by: cocobean Owned by: nobody
Priority: normal Milestone: R1/beta4
Component: System/POSIX Version: R1/Development
Keywords: strftime Cc: davidkaroly
Blocked By: Blocking:
Platform: All

Description (last modified by 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

Change History (9)

comment:1 by waddlesplash, 20 months ago

What happens with musl on Linux?

comment:2 by cocobean, 20 months ago

Description: modified (diff)

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

Last edited 19 months ago by cocobean (previous) (diff)

comment:3 by cocobean, 20 months ago

Last edited 20 months ago by cocobean (previous) (diff)

comment:4 by cocobean, 20 months ago

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

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

Ref: https://www.austingroupbugs.net/view.php?id=739

Version 2, edited 20 months ago by cocobean (previous) (next) (diff)

in reply to:  4 comment:5 by korli, 20 months ago

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.

comment:6 by davidkaroly, 18 months ago

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

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

comment:7 by davidkaroly, 18 months ago

Cc: davidkaroly added

comment:8 by cocobean, 17 months ago

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

comment:9 by waddlesplash, 17 months ago

Milestone: UnscheduledR1/beta4
Resolution: fixed
Status: newclosed
Note: See TracTickets for help on using tickets.