This is the mail archive of the
libc-locales@sourceware.org
mailing list for the GNU libc locales project.
Re: LC_TIME missing keywords
- From: "Carlos O'Donell" <carlos at redhat dot com>
- To: Steven Abner <pheonix at zoomtown dot com>
- Cc: libc-locales at sourceware dot org
- Date: Fri, 13 Sep 2013 16:06:59 -0400
- Subject: Re: LC_TIME missing keywords
- Authentication-results: sourceware.org; auth=none
- References: <C9F010A1-D739-43B9-8CAE-5942E9695407 at zoomtown 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.