[Bug localedata/4628] Provide rump locales with ISO 8601 variants for use with LC_TIME

[Bug localedata/4628] Provide rump locales with ISO 8601 variants for use with LC_TIME

[fweimer at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=4628

Florian Weimer <fweimer at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
                 CC|                            |fweimer at redhat dot com
             Blocks|                            |12731
         Resolution|WONTFIX                     |---
            Summary|Add iso 8601 date/time      |Provide rump locales with
                   |variants for EU countries   |ISO 8601 variants for use
                   |                            |with LC_TIME

--- Comment #6 from Florian Weimer <fweimer at redhat dot com> ---
We should add a couple of C.ISO8601 locales which can be combined with other
locales using LC_TIME.  It is does not make sense to add the three or so
variants we need to every locale.

Most people expect something like this for ISO 8601:

  2016-02-04 14:32:33 +01:00

But not any of the actually standardized formats:

  2016-02-04T14:32:33+01:00
  20160204T143233+0100


Referenced Bugs:

https://sourceware.org/bugzilla/show_bug.cgi?id=12731
[Bug 12731] [PATCH] en_CA date-time format doesn't respect CAN/CSA-Z234.4 - ISO
8601
-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug localedata/4628] Provide rump locales with ISO 8601 variants for use with LC_TIME

[fweimer at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=4628

--- Comment #8 from Florian Weimer <fweimer at redhat dot com> ---
(In reply to David Woodhouse from comment #7)
> In the 21st century where international communication is instant and
> frequent, colloquial use is changing.

But not towards ISO 8601.  People use “Thu, 2016-03-17 at 15:18 +0000” (taken
from <http://article.gmane.org/gmane.comp.mozilla.crypto/18562>).  But that's
not even close to ISO 8601 (which goes far beyond “YYYY-MM-DD”).

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug localedata/4628] Provide rump locales with ISO 8601 variants for use with LC_TIME

[dwmw2 at infradead dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=4628

David Woodhouse <dwmw2 at infradead dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dwmw2 at infradead dot org

--- Comment #7 from David Woodhouse <dwmw2 at infradead dot org> ---
In the 21st century where international communication is instant and frequent,
colloquial use is changing.

To use the parochial local date forms, especially mm/dd/yy and dd/mm/yy, is no
longer really acceptable in much of our day-to-day communication.

To use them in a context where they are seen outside your own locale is
impolite and unprofessional, and basically marks you as an idiot.

Even using them in the *local* context, the recipients still need to stop and
think about who you are and to whom you were speaking, to work out if this
really is "local form" or whether you're just another idiot from further afield
who can't be bothered to communicate properly. (If a European sends email to an
American and CC's another European, what does '5/6/16' mean? Just don't do it.)

I think there is a strong case not only for defining something like @ISO
versions of all the locales, but also for distributions to select those by
*default*. Much as we did a number of years ago for UTF-8. The colloquial use
was changing then too... it's just that some people were dragged along kicking
and screaming by the change of the default :)

This is one of the cases where we need to *help* the colloquial use change
faster than it already is.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug localedata/4628] Provide rump locales with ISO 8601 variants for use with LC_TIME

[nicolas.mailhot at laposte dot net]

https://sourceware.org/bugzilla/show_bug.cgi?id=4628

--- Comment #9 from Nicolas Mailhot <nicolas.mailhot at laposte dot net> ---
(In reply to Florian Weimer from comment #8)

> But not towards ISO 8601.  People use “Thu, 2016-03-17 at 15:18 +0000”
> (taken from <http://article.gmane.org/gmane.comp.mozilla.crypto/18562>). 
> But that's not even close to ISO 8601 (which goes far beyond “YYYY-MM-DD”).

That's a strawman, the datetime concept does not exist in human language, no
datetime will ever appear in human sentences (you'll get dates and times, the
format of which is perfectly appropriate in iso 8601 for humans).

Besides, iso 8601 is a very flexible spec, and provides for variations whenever
needed. The W3C profile is just a profile of iso 8601 (for HTML/XML code)

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug localedata/4628] Provide rump locales with ISO 8601 variants for use with LC_TIME

[carlos at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=4628

Carlos O'Donell <carlos at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |carlos at redhat dot com

--- Comment #10 from Carlos O'Donell <carlos at redhat dot com> ---
(In reply to Nicolas Mailhot from comment #9)
> (In reply to Florian Weimer from comment #8)
> 
> > But not towards ISO 8601.  People use “Thu, 2016-03-17 at 15:18 +0000”
> > (taken from <http://article.gmane.org/gmane.comp.mozilla.crypto/18562>). 
> > But that's not even close to ISO 8601 (which goes far beyond “YYYY-MM-DD”).
> 
> That's a strawman, the datetime concept does not exist in human language, no
> datetime will ever appear in human sentences (you'll get dates and times,
> the format of which is perfectly appropriate in iso 8601 for humans).
> 
> Besides, iso 8601 is a very flexible spec, and provides for variations
> whenever needed. The W3C profile is just a profile of iso 8601 (for HTML/XML
> code)

Would it suffice to provide C.utf8@iso8601 for the purposes of overriding
LC_TIME and allowing you to use ISO 8601 time representation in the fullest? We
need not duplicate all locales, ISO 8601 is language independent.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug localedata/4628] Provide rump locales with ISO 8601 variants for use with LC_TIME

[fweimer at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=4628

--- Comment #11 from Florian Weimer <fweimer at redhat dot com> ---
(In reply to Carlos O'Donell from comment #10)
> Would it suffice to provide C.utf8@iso8601 for the purposes of overriding
> LC_TIME and allowing you to use ISO 8601 time representation in the fullest?
> We need not duplicate all locales, ISO 8601 is language independent.

See comment 6, there are many different expectations what “ISO 8601” means. 
For size reasons, it's probably better to base the additional locales on C, not
C.utf8.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug localedata/4628] Provide rump locales with ISO 8601 variants for use with LC_TIME

[carlos at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=4628

--- Comment #12 from Carlos O'Donell <carlos at redhat dot com> ---
(In reply to Florian Weimer from comment #11)
> (In reply to Carlos O'Donell from comment #10)
> > Would it suffice to provide C.utf8@iso8601 for the purposes of overriding
> > LC_TIME and allowing you to use ISO 8601 time representation in the fullest?
> > We need not duplicate all locales, ISO 8601 is language independent.
> 
> See comment 6, there are many different expectations what “ISO 8601” means. 

Aesop's fable of the man, the boy, and the donkey ends with: "Please all and
you will please none."

I think the only tenable situation is to implement ISO 8601 as standardized.

> For size reasons, it's probably better to base the additional locales on C,
> not C.utf8.

Sure, that's fine, the ISO8601 representation needs only ASCII.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug localedata/4628] Provide rump locales with ISO 8601 variants for use with LC_TIME

[carlos at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=4628

--- Comment #14 from Carlos O'Donell <carlos at redhat dot com> ---
(In reply to Mike Frysinger from comment #13)
> (In reply to Carlos O'Donell from comment #10)
> 
> with the current locale system, a new C locale will only be useful if you
> speak English.  everyone else is still screwed.

I'm confused, why would they be screwed?

If you truly want ISO 8601, there are no language specific parts of the date
format. Do you have a copy of the standard to follow?

In ISO 8601 you never say "Monday" you always talk about the ordinal day number
of the week e.g. 1.

Therefore ISO 8601-compliant abday might just be 1, 2, 3, 4, 5, 6, 7?

Likewise with everything else. The whole point of ISO 8601 is to be an
international standard that is usable by everyone who can read numbers.

Does that clarify why non-English speakers should be able to set LC_TIME to
C@iso8601?

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug localedata/4628] Provide rump locales with ISO 8601 variants for use with LC_TIME

[vapier at sourceware dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=4628

--- Comment #13 from Mike Frysinger <vapier at sourceware dot org> ---
(In reply to Carlos O'Donell from comment #10)

with the current locale system, a new C locale will only be useful if you speak
English.  everyone else is still screwed.

https://sourceware.org/ml/libc-alpha/2016-04/msg00565.html

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug localedata/4628] Provide rump locales with ISO 8601 variants for use with LC_TIME

[gunnarhj at ubuntu dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=4628

--- Comment #15 from Gunnar Hjalmarsson <gunnarhj at ubuntu dot com> ---
On 2016-05-20 17:30, carlos at redhat dot com wrote:
> Does that clarify why non-English speakers should be able to set
> LC_TIME to C@iso8601?

I'm afraid it isn't that easy. LC_TIME includes month and weekday names, which
are often used by e.g. calendar apps.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug localedata/4628] Provide rump locales with ISO 8601 variants for use with LC_TIME

[carlos at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=4628

--- Comment #16 from Carlos O'Donell <carlos at redhat dot com> ---
(In reply to Gunnar Hjalmarsson from comment #15)
> On 2016-05-20 17:30, carlos at redhat dot com wrote:
> > Does that clarify why non-English speakers should be able to set
> > LC_TIME to C@iso8601?
> 
> I'm afraid it isn't that easy. LC_TIME includes month and weekday names,
> which are often used by e.g. calendar apps.

Then you don't want LC_TIME to follow ISO 8601?

Instead you want an arbitrary date and time that suits you but is easier than
making and maintaining your own locale?

Then we're back to Mike's suggestion in comment #13.

Which might look like `export LC_TIME=en_US:C@iso8601` which says use US
English language information for language-specific requirements, but consider
the territory to be generic and following ISO 8601.

I expect language specific entries would be:
- abday
- day
- abmon
- mon

I expect the territory specific entries would be:
- week
- d_t_fmt
- d_fmt
- t_fmt
- t_fmt_ampm
- am_pm

This is as Mike argues in his email.

In which case users would see their language-specific day names, month names,
etc, but the start of the week is always going to be Monday per ISO8601, and
date and time formats will be ISO8601.

The outliers are t_fmt_ampm, which doesn't exist in ISO8601, so it should IMO
be identical to t_fmt, and am_pm should be an empty set.

Thus do we all agree that we *don't* want ISO 8601?

That what we really want is layered locales with language/territory layering?

If you object, please describe some other kind of model that you're
considering.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug localedata/4628] Provide rump locales with ISO 8601 variants for use with LC_TIME

[gunnarhj at ubuntu dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=4628

--- Comment #17 from Gunnar Hjalmarsson <gunnarhj at ubuntu dot com> ---
On 2016-05-20 23:08, carlos at redhat dot com wrote:
> --- Comment #16 from Carlos O'Donell <carlos at redhat dot com> --- 
> (In reply to Gunnar Hjalmarsson from comment #15)
>> On 2016-05-20 17:30, carlos at redhat dot com wrote:
>>> Does that clarify why non-English speakers should be able to set 
>>> LC_TIME to C@iso8601?
>> 
>> I'm afraid it isn't that easy. LC_TIME includes month and weekday
>> names, which are often used by e.g. calendar apps.
> 
> Then you don't want LC_TIME to follow ISO 8601?

I want to encourage/make it easier (not enforce) to use ISO 8601 like date and
time formats. That's one thing. Another thing is that LC_TIME unfortunately(?)
includes localized month and weekday names.

> Which might look like `export LC_TIME=en_US:C@iso8601` which says use
> US English language information for language-specific requirements,
> but consider the territory to be generic and following ISO 8601.
> 
> I expect language specific entries would be:
> - abday
> - day
> - abmon
> - mon

If those could be broken out from LC_TIME somehow, it would indeed make some
things easier. Suppose it whouldn't be easily accomplished, though...

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug localedata/4628] Provide rump locales with ISO 8601 variants for use with LC_TIME

[yjf.victor at foxmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=4628

yjf.victor at foxmail dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |yjf.victor at foxmail dot com

--- Comment #18 from yjf.victor at foxmail dot com ---
This feature is pretty important actually. For many Asian companies, we have to
set the date format to yyyy-mm-dd (or maybe yyyy年mm月dd日) while sending
announcement, even when the announcement is in English language, such as some
international companies. Thus, it would be better to set the LC_TIME to ISO
8601 or RFC 3339 compatible format.

Currently, we set our date format to yyyy-MM-dd on Windows, and on Linux, the
"date" command is set as an alias, alias date='date --rfc-3339=seconds'. I
believe it would be better if we can set LC_TIME to something like "C@iso8601"
or maybe "POSIX@iso8601".

As for the format control of weekday name (%a) month name (%b) when you set
LC_TIME to C@iso8601, weekday name could be simply 0-6 (for Sunday to
Saturday), and month name could be the same as the month number, i.e. 1-12 (for
January to December). As a result, It isn't so difficult to have this locale.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug localedata/4628] Provide rump locales with ISO 8601 variants for use with LC_TIME

[joerg_bugzilla_sourceware at reisenweber dot net]

https://sourceware.org/bugzilla/show_bug.cgi?id=4628

Koerg Reisenweber <joerg_bugzilla_sourceware at reisenweber dot net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |joerg_bugzilla_sourceware@r
                   |                            |eisenweber.net

--- Comment #19 from Koerg Reisenweber <joerg_bugzilla_sourceware at reisenweber dot net> ---
(In reply to Carlos O'Donell from comment #16)
[...]
> Which might look like `export LC_TIME=en_US:C@iso8601` which says use US
> English language information for language-specific requirements, but
> consider the territory to be generic and following ISO 8601.
> 
> I expect language specific entries would be:
> - abday
> - day
> - abmon
> - mon
> 
> I expect the territory specific entries would be:
> - week
> - d_t_fmt
> - d_fmt
> - t_fmt
> - t_fmt_ampm
> - am_pm
> 
> This is as Mike argues in his email.
> 
> In which case users would see their language-specific day names, month
> names, etc, but the start of the week is always going to be Monday per
> ISO8601, and date and time formats will be ISO8601.
> 
> The outliers are t_fmt_ampm, which doesn't exist in ISO8601, so it should
> IMO be identical to t_fmt, and am_pm should be an empty set.
> 
> Thus do we all agree that we *don't* want ISO 8601?
> 
> That what we really want is layered locales with language/territory layering?
> 
> If you object, please describe some other kind of model that you're
> considering.

sounds excellent, any progress on this?
/jOERG

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug localedata/4628] Provide rump locales with ISO 8601 variants for use with LC_TIME

[joerg_bugzilla_sourceware at reisenweber dot net]

https://sourceware.org/bugzilla/show_bug.cgi?id=4628

--- Comment #20 from Koerg Reisenweber <joerg_bugzilla_sourceware at reisenweber dot net> ---
AM/PM probably isn't a feature much asked for by users who want "ISO 8601" date

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug localedata/4628] Provide rump locales with ISO 8601 variants for use with LC_TIME

[dwmw2 at infradead dot org]

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.

[Bug localedata/4628] Provide rump locales with ISO 8601 variants for use with LC_TIME

[carlos at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=4628

Carlos O'Donell <carlos at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           See Also|                            |https://bugzilla.mozilla.or
                   |                            |g/show_bug.cgi?id=1509096

--- Comment #22 from Carlos O'Donell <carlos at redhat dot com> ---
(In reply to David Woodhouse from comment #21)
> Any progress on this?

I am not aware of any progress on this issue.

Let me summarize the current state over the 14+ years this bug has been open.

I feel that ISO 8601 is a red-herring here, and the vast majority of users are
simply talking about d_fmt and the default becoming YYYY-MM-DD for their
particular use case.

There are three positions that can be taken on default value of d_fmt:

(a) A locale represents the information for an application to use to present
such information to someone local in that locale. Thus d_fmt should be used
when exchanging information locally (whatever that means). An application may
make a choice that in the context of the application's use of the data choose
to present the data in a more interoperable unambiguous format, a 21st century
way, e.g. YYYY-MM-DD for d_fmt.

(b) A locale represents the default way information should be presented, and in
the 21st century, this means d_fmt should be YYYY-MM-DD.

(c) The framework should allow for easy customization of the pattern used for
d_fmt, without loosing the language-specific localization in the rest of
LC_TIME.

Several early responders to this issue in 2007 took the position of (a), and
that no further work was required in glibc. Users were rightly upset because
the solution of making your own locale is not well supported by glibc as a
process in general. Also users only really wanted d_fmt to be YYYY-MM-DD, and
everything else the same.

Some users over time have taken the position (b).

Recent glibc developers have started to come around to (c), and it follows on
from the fact that ICU and other libraries do allow a certain amount of dynamic
customization of date format patterns, as seen in the solution for Thunderbird
here: 
"Implement pref overrides for date and time formats:
intl.date_time.pattern_override.date_* and
intl.date_time.pattern_override.time_* (was: TB 60 on Linux: Setting date
locale to LC_TIME=en_DK.utf8 no longer outputs yyyy-MM-dd format)"
https://bugzilla.mozilla.org/show_bug.cgi?id=1426907

To date we have several suggestions for a way forward:

(1) Add @ variants to all locales.
- Duplicate all locales, rename, and change d_fmt to %Y-%m-%d (with clever
include usage to reduce duplication).

(2) Add @ variants to a few key locales.
- Solution (1) but reduce the overall work and gives some users a solutions.

(3) Implement a language:territory layering.
- Provide a new format for specifying LC_TIME that allows a user to layer
language and territory information. LC_TIME would need to be split into
language-specific entries, and territory-specific entries (language neutral),
and allow layering.

None of (1), (2) or (3) have been implemented to date.

I see maybe another way forward:

(4) New pattern with override selection.

Following the Mozilla and ECMA Script recommendations it might be more possible
to define variants of d_fmt, and allow users to pick a variant e.g.

In environment:
LC_TIME=en_US,d_fmt={iso8601}

In locale sources:
d_fmt            "%m//%d//%Y"
% Variant {iso8601} pattern for d_fmt.
d_fmt_iso8601    "%Y-%M-%d"

Where the locale sources provide tested canonical patterns for the variants.
Then users can pick the variants and we can easily add variants. At the
implementation level we would need to change a pointer after parsing the env
var and we would also break the sharing of some of the pages of the mmap'd
binary locale.

Notes:
https://bugzilla.mozilla.org/show_bug.cgi?id=1426907
https://bugzilla.mozilla.org/show_bug.cgi?id=1509096
https://unicode-org.atlassian.net/browse/CLDR-5769
https://unicode-org.atlassian.net/browse/CLDR-12027
https://github.com/tc39/proposal-intl-datetime-style

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug localedata/4628] Provide rump locales with ISO 8601 variants for use with LC_TIME

[carlos at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=4628

Carlos O'Donell <carlos at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           See Also|                            |https://bugzilla.mozilla.or
                   |                            |g/show_bug.cgi?id=1426907

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug localedata/4628] Provide rump locales with ISO 8601 variants for use with LC_TIME

[carlos at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=4628

Carlos O'Donell <carlos at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           See Also|                            |https://unicode-org.atlassi
                   |                            |an.net/browse/CLDR-5769

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug localedata/4628] Provide rump locales with ISO 8601 variants for use with LC_TIME

[carlos at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=4628

Carlos O'Donell <carlos at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           See Also|                            |https://unicode-org.atlassi
                   |                            |an.net/browse/CLDR-12027

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug localedata/4628] Provide rump locales with ISO 8601 variants for use with LC_TIME

[nicolas.mailhot at laposte dot net]

https://sourceware.org/bugzilla/show_bug.cgi?id=4628

--- Comment #23 from Nicolas Mailhot <nicolas.mailhot at laposte dot net> ---
Really the whole thing has been blown out of proportion by people who did not
want to work on this, piling strawmen over strawmen.

People asked to have the choice to use a new standard way of presenting time
and dates, a way that has been normalised by ISO, IETF, W3C etc, a way that has
been available by default in other OSes for about 20 years, a way that works
better for human and for software (because it sorts properly).

In other words, exactly what happened before when people switched to 24h time,
but to read some comments implementing 24h time would have required switching
all locales to some fake C unilocale, translating hour names into “neutral”
English.

All people ask for is switching numeric representations to a common format
(yyyy-mm-dd, standard iso weeks…), keeping human day names as-is. 

The only part remotely controversial are iso weeks starting on monday but they
are mostly used by businesses and businesses are the first ones to clamour for
something that does not break when you pass a border (and besides most locales
interested in ISO 8601 dates are already using ISO weeks).

And if locale structure as it exists today is badly suited to this need maybe
locale structure needs to evolve to keep up with human needs?

Unfortunately, free software continues to be unfriendly to non-US users. I
don’t know why its the case, but it’s the sole system that still has problems
selecting A4 paper or distinguishing between input system and input language.
All things MS solved in Office and Windows circa 1995.

Makes you proud of the people that managed the switch to UTF-8 given how
controversial those changes seem to be there (they are not controversial in
other OSes).

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug localedata/4628] Provide rump locales with ISO 8601 variants for use with LC_TIME

[dwmw2 at infradead dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=4628

--- Comment #24 from David Woodhouse <dwmw2 at infradead dot org> ---
Thanks, Carlos.

(In reply to Carlos O'Donell from comment #22) 
> I feel that ISO 8601 is a red-herring here, and the vast majority of users
> are simply talking about d_fmt and the default becoming YYYY-MM-DD for their
> particular use case.

Agreed.

> There are three positions that can be taken on default value of d_fmt:

It seems to me that these positions are retroactively (re)defining the very
semantics of d_fmt, and the purposes for which e.g. strftime("%x") should be
used. Yet applications have been using it in its current form for decades, and
it has been received wisdom that "well-behaved" applications will use the
locale format for the date.

We can change precisely what date format the applications get when they use 
d_fmt — that is precisely the *point* of it, after all. But I'd suggest that it
doesn't make much sense to talk about when/whether applications should use it
at all. That ship has sailed.

> (a) A locale represents the information for an application to use to present
> such information to someone local in that locale. Thus d_fmt should be used
> when exchanging information locally (whatever that means). An application
> may make a choice that in the context of the application's use of the data
> choose to present the data in a more interoperable unambiguous format, a
> 21st century way, e.g. YYYY-MM-DD for d_fmt.

It took me a while to parse the difference between (a) and (b) here, and the
distinction between "for local only viewing" in (a) vs. "default" in (b).

I think the final sentence of (a) should say that an application may explicitly
use e.g. YYYY-MM-DD (%Y-%m-%d) *instead* of using d_fmt (%x).

Of course, in today's interconnected world the only application that can know
its output will only be consumed locally is Snapchat. Anything that outputs
text which can be shared via email/screenshots/files/databases would need to
eschew the legacy d_fmt and explicitly use %Y-%m-%d instead.

On top of which, even if an application *could* know that it's displaying only
to a local user, the archaic dd/mm/yy form of en_GB is *still* the wrong thing
to display. The world has changed, with computers now being considered "broken"
if they cannot instantly communicate with others on a different continent, and
the legacy dd/mm form is a poor choice even for *local* communication because
users are inundated with dates in 'wrong' mm/dd form that makes it ambiguous.

Applications should just use %Y-%m-%d everywhere, unconditionally.

So if we choose (a) then we should change the strftime(3) man page to make it
clear that the %x format is deprecated and should never be used, much like the
warning we already have on %D. And we should patch all the applications in the
world, something like this...

-    strftime(buf, sizeof(buf), _("The date is %x"), tm);
+    strftime(buf, sizeof(buf), _("The date is %Y-%m-%d", tm);


> (b) A locale represents the default way information should be presented, and
> in the 21st century, this means d_fmt should be YYYY-MM-DD.

This is my understanding of the current position. Well-behaved applications
*should* use d_fmt, and it *should* do something appropriate based on which
country, and which millennium, the user is living in.

Instead of deprecating '%x' and declaring that decent applications will change
to manually use %Y-%m-%d, which is the logical conclusion of choice (a), choice
(b) would simply use the existing flexibility to make existing applications do
the right thing seamlessly. It seems like the better choice to me.

> (c) The framework should allow for easy customization of the pattern used
> for d_fmt, without loosing the language-specific localization in the rest of
> LC_TIME.

I don't even know that this needs to be selectable at run time. A build time
choice could be perfectly sufficient, wouldn't it?

Let's switch viewpoints and look at the user/application experience rather than
the implementation side.

Let's also take a slightly less contentious example which really is just a bug.
Poland *officially* adopted the YYYY-MM-DD format in 2002, yet 'LC_TIME=pl_PL
date +%x' still seems to output the legacy 07.01.2022 format. Shouldn't that
one just be fixed in the next glibc release? Should we file a separate bug for
it?

A *distribution* might then want to revert that change, perhaps if shipping the
new glibc as an update to an existing system (to avoid breaking some
admittedly-already-broken screenscraping scripts). So making it a build-time
option would be useful.

But the next major release of the distribution would probably just use the
"new" post-2002 d_fmt for pl_PL.

For the individual user, the experience would just be that in a new version,
the behaviour gets updated. And if they *really* object to the fixed behaviour,
they still have the (runtime) option of building their own locale to regress it
for themselves. It's not trivial, but it doesn't *need* to be.

And if we can do it for pl_PL (which we absolutely should), then why shouldn't
we do the same for *all* locales? Because this far into the 21st century,
%Y-%m-%d is the only sane way to represent numeric dates.

> I see maybe another way forward:
> 
> (4) New pattern with override selection.
> 
> Following the Mozilla and ECMA Script recommendations it might be more
> possible to define variants of d_fmt, and allow users to pick a variant e.g.
> 
> In environment:
> LC_TIME=en_US,d_fmt={iso8601}
> 
> In locale sources:
> d_fmt            "%m//%d//%Y"
> % Variant {iso8601} pattern for d_fmt.
> d_fmt_iso8601    "%Y-%M-%d"

If you do proceed with runtime options, please ensure that the *default* is
YYYY-MM-DD and that the suffix is required to go back to the legacy form. Or
define *both* 'iso8601' and 'legacy' suffixes and allow the system default to
be configured at build time (and *that* should default to iso8601).

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug localedata/4628] Provide rump locales with ISO 8601 variants for use with LC_TIME

[nicolas.mailhot at laposte dot net]

https://sourceware.org/bugzilla/show_bug.cgi?id=4628

--- Comment #25 from Nicolas Mailhot <nicolas.mailhot at laposte dot net> ---
From a change management POW there is no need to redefine defaults.

However, there *is* a need to have format selection happen at the locale name
level. That’s the simplest way both to enable adopters (that will set the new
local and then lobby their distro to select it at install time) and to protect
stragglers (that will do the reverse on systems where a broken app/script can
not accommodate the new format).

UTF8 migration shows local-name-level changes are manageable. And it does not
matter if the old locale identifier corresponds to the old or the new format.

IMHO something finer grained is bound to cause problems because there won’t be
any simple exit hatch for people who have to live with broken scripts or apps.

-- 
You are receiving this mail because:
You are the assignee for the bug.