The following issue has been UPDATED.
======================================================================
http://austingroupbugs.net/view.php?id=81
======================================================================
Reported By: geoffclare
Assigned To: ajosey
======================================================================
Project: 1003.1(2008)/Issue 7
Issue ID: 81
Category: Base Definitions and Headers
Type: Clarification Requested
Severity: Objection
Priority: normal
Status: Interpretation Required
Name: Petr Baudis
Organization: SUSE Labs / Novell
User Reference:
Section: LC_TIME
Page Number: 159
Line Number: 4921
Final Accepted Text: http://austingroupbugs.net/view.php?id=81#c133
======================================================================
Date Submitted: 2009-06-29 09:40 UTC
Last Modified: 2009-07-02 18:02 UTC
======================================================================
Summary: am_pm value in locales that do not distinguish
between am and pm
Description:
OBJECTION Enhancement Request
Number 4
pasky:xxxxxxx Defect in XBD LC_TIME (rdvk#
1)
{0} Wed, 18 Mar 2009 23:13:07
GMT
_____________________________________________________________________________
http://www.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap07.html#tag_07_03_05
:
The am_pm description says that it shall "define the appropriate
representation of the ante-meridiem and post-meridiem strings,
corresponding to the %p conversion specification."
However, it is not clear what the appropriate representation should be,
in locales that do not distinguish between am and pm. Currently, it
seems OpenSolaris and OpenBSD have AM;PM here even for locales with no
am/pm convention while glibc tries to have empty strings here if am/pm
is not distinguished within the locale.
Currently, there is a "silent dispute" going on between Ulrich Drepper
and GNOME developers on what the am_pm value should be. It would be
nice to have this clarified in the standard so that application
programmers can find reliable values here.
Desired Action:
The am_pm description should be clarified on what should the content be
for locales not distinguishing between AM/PM, or whether that is
implementation-defined.
======================================================================
----------------------------------------------------------------------
(0000133) geoffclare (reporter) - 2009-06-29 09:44
http://austingroupbugs.net/view.php?id=81#c133
----------------------------------------------------------------------
It was noted that if t_fmt_ampm is an empty string, then applications
should not use the value of am_pm.
This should go down the interpretations track
The standard does not address this issue, concerns are being
forwarded to the sponsor.
Consider as a revision for a future edition, requiring that
am_pm be empty if t_fmt_ampm is an emptry string
This would also need to be noted in the APPLICATION USAGE of related
utilities/functions.
|