Bug 25923 - Regression: en_US date_fmt and d_t_fmt and "%a %d %b" vs. "%a %b %e"
Summary: Regression: en_US date_fmt and d_t_fmt and "%a %d %b" vs. "%a %b %e"
Status: NEW
Alias: None
Product: glibc
Classification: Unclassified
Component: localedata (show other bugs)
Version: 2.29
: P2 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-05-05 13:57 UTC by Carlos O'Donell
Modified: 2020-05-05 22:02 UTC (History)
2 users (show)

See Also:
Host:
Target:
Build:
Last reconfirmed:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Carlos O'Donell 2020-05-05 13:57:07 UTC
In commit 7395f3a0efad9fc51bb54fa383ef6524702e0c49, which is discussed here:
https://sourceware.org/pipermail/libc-alpha/2018-December/100227.html

The date_fmt was defined for en_US to correct the 24h clock issue.

What was not discussed at the time, perhaps overlooked, is that the display order of the month and day was changed.

For 20 years date_fmt has printed:
date +"%a %b %e"
Tue May  5

For 23 years d_t_fmt has printed:
date +"%a %d %b"
Tue 05 May

When commit 7395f3a0efad9fc51bb54fa383ef6524702e0c49 fixed the 24h change it also changed the month and day ordering.

This is a change in behaviour that should be discussed. We should at a minimum revert the monty and day ordering change until we can agree what should be done for date_fmt or d_t_fmt.

My opinion is that we should minimize the amount of change being done, and simply keep d_t_fmt and date_fmt different, but retain the fixed 12h clock as intended by the original fix for bug 24046.