Bug 1830623 - glibc: Inconsistency for locale data for en_US between d_t_fmt and date_fmt.
Summary: glibc: Inconsistency for locale data for en_US between d_t_fmt and date_fmt.
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: glibc
Version: 32
Hardware: All
OS: All
unspecified
low
Target Milestone: ---
Assignee: Carlos O'Donell
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2020-05-03 03:29 UTC by Matthew Crews
Modified: 2020-08-04 13:17 UTC (History)
11 users (show)

Fixed In Version: glibc-2.31.9000-20
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-08-04 13:17:38 UTC
Type: Bug


Attachments (Terms of Use)
Patch file to correct the date format for en_US (512 bytes, patch)
2020-05-03 03:29 UTC, Matthew Crews
no flags Details | Diff


Links
System ID Priority Status Summary Last Updated
Sourceware 25923 P2 NEW Regression: en_US date_fmt and d_t_fmt and "%a %d %b" vs. "%a %b %e" 2020-08-04 13:12:32 UTC

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):
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

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

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:

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.

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

I personally think your proposed changes are good.

Cheers.

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.


Note You need to log in before you can comment on or make changes to this bug.