From: "dwmw2 at infradead dot org" <sourceware-bugzilla@sourceware.org>
To: libc-locales@sourceware.org
Subject: [Bug localedata/4628] Provide rump locales with ISO 8601 variants for use with LC_TIME
Date: Tue, 21 Dec 2021 14:18:56 +0000 [thread overview]
Message-ID: <bug-4628-716-Z2hIiIMS8Z@http.sourceware.org/bugzilla/> (raw)
In-Reply-To: <bug-4628-716@http.sourceware.org/bugzilla/>
https://sourceware.org/bugzilla/show_bug.cgi?id=4628
--- Comment #21 from David Woodhouse <dwmw2 at infradead dot org> ---
Any progress on this?
The legacy mm/dd and dd/mm forms started becoming obsolescent the moment it
became possible to conduct written communication between the US and Europe in
less time than it takes a steam ship to physically cross the Atlantic Ocean.
As a European, I am constantly bombarded with dates in the US-local form. From
crappy software, crappy web sites, and crappy people.
So when I see "1/2/2021" I have *absolutely no idea* whether that means January
2nd or February 1st. Even if it's the "right" historical format for my locale,
it's still ambiguous. And that's why it's utterly wrong to be using that format
— even the "correct" variant of it — in the 21st century.
Well-behaved programs should only *ever* use the YYYY-MM-DD form for numeric
dates, and *never* the non-inclusive, ambiguous, parochial local forms mm/dd or
dd/mm.
--
You are receiving this mail because:
You are the assignee for the bug.
next prev parent reply other threads:[~2021-12-21 14:18 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <bug-4628-716@http.sourceware.org/bugzilla/>
2016-02-04 13:57 ` fweimer at redhat dot com
2016-05-20 12:44 ` dwmw2 at infradead dot org
2016-05-20 12:44 ` fweimer at redhat dot com
2016-05-20 13:20 ` nicolas.mailhot at laposte dot net
2016-05-20 13:55 ` carlos at redhat dot com
2016-05-20 13:59 ` fweimer at redhat dot com
2016-05-20 14:04 ` carlos at redhat dot com
2016-05-20 19:13 ` vapier at sourceware dot org
2016-05-20 19:13 ` carlos at redhat dot com
2016-05-20 22:36 ` gunnarhj at ubuntu dot com
2016-05-20 22:37 ` carlos at redhat dot com
2016-05-20 23:28 ` gunnarhj at ubuntu dot com
2017-08-02 13:57 ` yjf.victor at foxmail dot com
2018-06-24 0:50 ` joerg_bugzilla_sourceware at reisenweber dot net
2018-06-24 0:55 ` joerg_bugzilla_sourceware at reisenweber dot net
2021-12-21 14:18 ` dwmw2 at infradead dot org [this message]
2022-01-06 22:03 ` carlos at redhat dot com
2022-01-06 22:04 ` carlos at redhat dot com
2022-01-06 22:04 ` carlos at redhat dot com
2022-01-06 22:04 ` carlos at redhat dot com
2022-01-07 9:48 ` nicolas.mailhot at laposte dot net
2022-01-07 10:58 ` dwmw2 at infradead dot org
2022-01-07 11:29 ` nicolas.mailhot at laposte dot net
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=bug-4628-716-Z2hIiIMS8Z@http.sourceware.org/bugzilla/ \
--to=sourceware-bugzilla@sourceware.org \
--cc=libc-locales@sourceware.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).