Created attachment 1684373 [details] Patch file to correct the date format for en_US Description of problem: Date format for en_US locale has incorrect conventional United States date formatting. This data is stored in glibc/localedata/locales/en_US file Version-Release number of selected component (if applicable): 2.31 How reproducible: Always Actual results: when using date command, outputs in format "%a %d %b %Y %r %Z", for example Sat 02 May 2020 08:25:05 PM MST Expected results: United States convention places month before date, in format "%a %B %d %Y %r %Z", for example Sat May 02 2020 08:25:05 PM MST Additional info: Patch file attached to be applied to glibc/localedata/locales/en_US
The change in behaviour is recent and was caused by another fix. The following upstream commit fixes the 24h time issue, but also transposes the month and day: commit 7395f3a0efad9fc51bb54fa383ef6524702e0c49 Author: Aurelien Jarno <aurelien> Date: Mon Dec 31 00:29:53 2018 +0100 en_US: define date_fmt (bug 24046) The en_US locale use a 12h am/pm format in both d_fmt and d_t_fmt, which is correct, but does not define date_fmt. This causes the default value to be used, which is in 24h format. This patch adds the date_fmt entry to the en_US locale with the same value as d_t_fmt as the latter already includes the timezone. Changelog [BZ #24046] * localedata/locales/en_US (date_fmt): Add, set to "%a %d %b %Y %r %Z". This change seemed sensible because en_US has been using d_t_fmt set to "%a %d %b %Y %r %Z" since 1997. However, the date_fmt specifier was added in 2000 and has had the default of "%a %b %e %H:%M:%S %Z %Y" since then. This is going to go upstream to discuss the issue and what should be the default. There is a conflict between d_t_fmt and date_fmt and that needs to be resolved.
I have suggested changes here which revert the incidental changes made to the format: https://sourceware.org/pipermail/libc-alpha/2020-May/113641.html The format would revert to having month first, but would retain the 12h change (since this is more acceptable to the en_US users). I am waiting for upstream to have time to review the suggestion.
Carlos, I personally think your proposed changes are good. Cheers.
We are going to try fix this in upstream glibc 2.32. I've added it the blockers for the release. I'll get a patch posted today.
Fixed with commit 3e8e5d3396dbe9732053a58f46aef199772aaae7 in Rawhide glibc.