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

["joerg_bugzilla_sourceware at reisenweber dot net" <sourceware-bugzilla@sourceware.org>]

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.