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

["carlos at redhat dot com" <sourceware-bugzilla@sourceware.org>]

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.