sort -M Locale Month Parsing Gap

[sylvestre]

Component

sort

Description

uutils' sort -M only hardcodes recognition of English 3-letter months (JAN..DEC) and does not parse month abbreviations according to the LC_TIME/LC_ALL locale; GNU sort parses them using the locale's month table.

Test / Reproduction Steps

(A locale with non-English month abbreviations is required, such as de_DE.UTF-8.):
$ printf 'Mär\nJan\n' | LC_ALL=de_DE.UTF-8 sort -M
$ printf 'Mär\nJan\n' | LC_ALL=de_DE.UTF-8 ./target/release/coreutils sort -M

• GNU: JAN comes first
• uutils: JAN comes last

Impact

In non-LC_ALL=C/non-English environments, the -M sorting result is incorrect, and scripts relying on localized month text will fail.

[ChrisDryden]

Related issue with months: #3123

Also corresponds to GNU test tests/misc/sort-month

[ChrisDryden]

@sylvestre one thing that would help with whoever takes this on is the alignment on the high level implementation approach?

I did some prototyping to see how similar things are resolved and the high level approach was using the ICU4X library for getting the locale months. The library that appears to correspond with the data we need is icu_datetime using the use icu_datetime::provider::neo::{DatetimeNamesMonthGregorianV1, MonthNames}; Then the approach is in the i18n folder creating a new "Months" file that handles the parsing of the months using the time locale?

Is that a high level approach that aligns with what you're thinking?

[ChrisDryden]

This is the implementation using that approach: #9722