Re: LC_TIME missing keywords

["Carlos O'Donell" <carlos at redhat dot com>]

On 09/13/2013 03:28 PM, Steven Abner wrote:
> Hello list,
>  Hope this is the correct list, bug-glibc-locales@gnu.org listed in locale files bounced.

This is the right list, sorry the other one bounced,
we should look into that.

>  I was working on a parser for my source code and found three locales that lack POSIX "mandatory" keywords.
> Almost all lack "era*", which is OK, but the ones I question are the three that lacked "t_fmt_ampm" keyword. 
> Two locales have "am_pm" defined as a non-nul string values. Locale "km_KH" has "t_fmt_ampm" commented out.
> Locale "ff_SN" has "t_fmt_ampm" missing. For these two should I uncomment the one and provide a non-nul string
> for the other? The third "ug_CN" has nul strings for "am_pm" and missing "t_fmt_ampm". That one I assume just provide a
> nul string, but your files, I just started locales, you tell me please.
>  That question above leads to two other questions. Some locales have a "am_pm" defined but a "t_fmt_ampm" defined
> as does not use 12 hour format (nul string), what should be done in this case as far as strf/ptime()? Conversely, when
> one uses a 12 hour format ("t_fmt_ampm" keyword, %p specifically) should the "am_pm" be defined as a non-nul string?
> Examples:  af_ZA, ff_SN, zh_SG; br_FR, bg_BG, cs_CZ.
>  Those questions lead to this: could you email POSIX and request that %k, %l be added to the appropriate time interfaces?
> I, as a peon, don't carry any weight and had complications just getting typos changed. And was unaware of their
> existence until working with these locale files.
> I am using glibc-2.18 data, IEEE Std 1003.1, 2013 Edition.

I have no idea what to say about the bugs you report,
only that we need a detailed example with code which
shows the problem and you should probably file a bug
in bugzilla so we can track this.

Once we fix glibc we can then talk about going to
POSIX to talk about supported formats, which I doubt
will change without seriously well formed rationale
for the need to change.

Cheers,
Carlos.