View Issue Details

IDProjectCategoryView StatusLast Update
00000811003.1(2008)/Issue 7Base Definitions and Headerspublic2009-10-09 16:57
Reportergeoffclare Assigned Toajosey  
PrioritynormalSeverityObjectionTypeClarification Requested
Status Interpretation RequiredResolutionAccepted As Marked 
NamePetr Baudis
OrganizationSUSE Labs / Novell
User Reference
SectionLC_TIME
Page Number159
Line Number4921
Interp StatusApproved
Final Accepted Text0000081:0000133
Summary0000081: 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.
TagsNo tags attached.

Relationships

related to 0001307 Closed 1003.1(2016/18)/Issue7+TC2 am_pm value in locales that do not distinguish between am and pm (again) 

Activities

geoffclare

2009-06-29 09:44

manager   bugnote:0000133

Last edited: 2009-10-09 16:56

Interpretation response
------------------------
The standard does not speak to this issue, and as such
no conformance distinction can be made between alternative
implementations based on this. This is being referred to the
sponsor.

Rationale:
-------------

It was noted that if t_fmt_ampm is an empty string, then applications
should not use the value of am_pm.


Notes to the Editor (not part of this interpretation):
-------------------------------------------------------

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.

Issue History

Date Modified Username Field Change
2009-06-29 09:40 geoffclare New Issue
2009-06-29 09:40 geoffclare Status New => Under Review
2009-06-29 09:40 geoffclare Assigned To => ajosey
2009-06-29 09:40 geoffclare Name => Geoff Clare
2009-06-29 09:40 geoffclare Organization => The Open Group
2009-06-29 09:40 geoffclare Section => LC_TIME
2009-06-29 09:40 geoffclare Page Number => 0
2009-06-29 09:40 geoffclare Line Number => 0
2009-06-29 09:41 geoffclare Tag Attached: real bug in aardvark
2009-06-29 09:44 geoffclare Note Added: 0000133
2009-06-29 09:44 geoffclare Status Under Review => Interpretation Required
2009-06-29 09:44 geoffclare Resolution Open => Accepted As Marked
2009-06-29 09:47 geoffclare Final Accepted Text => Note: 0000133
2009-06-29 09:53 geoffclare Final Accepted Text Note: 0000133 => 0000081:0000133
2009-06-29 09:54 geoffclare Tag Attached: needs page and line numbers
2009-07-02 18:02 Don Cragun Name Geoff Clare => Petr Baudis
2009-07-02 18:02 Don Cragun Organization The Open Group => SUSE Labs / Novell
2009-07-02 18:02 Don Cragun Page Number 0 => 159
2009-07-02 18:02 Don Cragun Line Number 0 => 4921
2009-07-02 18:02 Don Cragun Tag Detached: needs page and line numbers
2009-08-06 15:51 Don Cragun Tag Detached: real bug in aardvark
2009-08-11 16:34 Don Cragun Interp Status => Pending
2009-09-17 15:41 nick Interp Status Pending => Proposed
2009-10-09 16:56 ajosey Note Edited: 0000133
2009-10-09 16:57 ajosey Interp Status Proposed => Approved
2010-09-20 09:22 geoffclare Tag Attached: issue8
2019-12-18 15:36 geoffclare Relationship added related to 0001307
2019-12-18 15:38 geoffclare Tag Detached: issue8