Bug 1830623

Summary: glibc: Inconsistency for locale data for en_US between d_t_fmt and date_fmt.
Product: [Fedora] Fedora Reporter: Matthew Crews <mattcrews>
Component: glibcAssignee: Carlos O'Donell <codonell>
Status: CLOSED RAWHIDE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: low Docs Contact:
Priority: unspecified    
Version: 32CC: aoliva, arjun.is, codonell, dj, fweimer, law, mfabian, pfrankli, redhat, rth, siddhesh, sipoyare
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: All   
Fixed In Version: glibc-2.31.9000-20 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2020-08-04 13:17:38 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Description Flags
Patch file to correct the date format for en_US none

Description Matthew Crews 2020-05-03 03:29:28 UTC
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):

How reproducible:

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

Comment 1 Carlos O'Donell 2020-05-05 13:33:05 UTC
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@aurel32.net>
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.
            [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.

Comment 2 Carlos O'Donell 2020-05-12 13:09:20 UTC
I have suggested changes here which revert the incidental changes made to the format:


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.

Comment 3 Matthew Crews 2020-05-12 17:35:02 UTC

I personally think your proposed changes are good.


Comment 6 Carlos O'Donell 2020-06-30 13:27:49 UTC
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.

Comment 7 Carlos O'Donell 2020-08-04 13:17:38 UTC
Fixed with commit 3e8e5d3396dbe9732053a58f46aef199772aaae7 in Rawhide glibc.