Austin Group Defect Tracker

Aardvark Mark IV


Viewing Issue Simple Details Jump to Notes ] Issue History ] Print ]
ID Category Severity Type Date Submitted Last Update
0001307 [1003.1(2016/18)/Issue7+TC2] Base Definitions and Headers Comment Clarification Requested 2019-12-18 15:35 2024-06-11 09:08
Reporter geoffclare View Status public  
Assigned To
Priority normal Resolution Accepted As Marked  
Status Closed  
Name Geoff Clare
Organization The Open Group
User Reference
Section 7.3.5.1 LC_TIME Locale Definition
Page Number 160
Line Number 5085
Interp Status Approved
Final Accepted Text See Note: 0004762.
Summary 0001307: am_pm value in locales that do not distinguish between am and pm (again)
Description The Notes to the Editor in the Interpretation response in bug 0000081 say:
Consider as a revision for a future edition, requiring that
am_pm be empty if t_fmt_ampm is an empty string

This would also need to be noted in the APPLICATION USAGE of related
utilities/functions.

This is an instruction to the working group to consider making a change, not an instruction to the editor to make a change. I am submitting this bug so that we can duly consider precisely what, if any, changes to make.
Desired Action Change:
The operand shall consist of two strings, separated by a <semicolon>, each surrounded by double-quotes. The first string shall represent the ante-meridiem designation, the last string the post-meridiem designation.
to:
If the t_fmt_ampm string is not empty, the am_pm operand shall consist of two strings, separated by a <semicolon>, each surrounded by double-quotes; the first string shall represent the ante-meridiem designation, the last string the post-meridiem designation. If the t_fmt_ampm string is empty, the am_pm operand shall be an empty string.

If this change is agreed, then work out what other changes are needed.
Tags issue8
Attached Files

- Relationships
related to 0000081Interpretation Requiredajosey 1003.1(2008)/Issue 7 am_pm value in locales that do not distinguish between am and pm 
child of 0000466Closedajosey 1003.1(2008)/Issue 7 date +%C problem 

-  Notes
(0004688)
geoffclare (manager)
2019-12-18 15:38

Since bug 0000081 does not contain details of a change to be applied in Issue 8, I have removed the issue8 tag from it. It still stands as a formal Interpretation response to the issue that was raised in that bug.
(0004689)
shware_systems (reporter)
2019-12-18 18:54
edited on: 2019-12-18 19:08

I'd be more in favor of requiring, at a minimum, "";"" be the default value for am_pm, so whatever processing using that sees zero length strings as the associated values, i.e. the search for a ';' will always succeed. This reduces code size as no tests for ';' not found are mandated.

A case can be made too that since AM and PM are abbreviations of Latin, this is invariant across all locales also for a Gregorian calendar, with the am_pm value used only to specify if lower, mixed, or upper case versions of those are preferred; there should never be zero length values for either. Even where a country prefers to use a national languge translation for "before noon" or "after noon", an appropriate abbreviation could be represented, e.g. "VM";"AM" representing "vor mittag" and "ab mittag" in a german locale.

As such %r is valid for all locales too, never unsupported, and a default string of "%I:%M%p" for t_fmt_ampm is appropriate. It is a more a defining specification of locale data does not say an alternate format is required. If a locale definition says always use 24 hour values, or always provide seconds as in the POSIX locale, it's then on that locale data to specify a string like "%H%M" or "%I:%M:%S %p" (as strftime() does), not leave it empty.

Even though adding the string to values of a 24 hour usage is nominally superfluous, it still accents the value is a morning or evening time so isn't entirely redundant. I wouldn't preclude values like "%H:%M %p" therefore.

(0004762)
Don Cragun (manager)
2020-01-30 16:57

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

Rationale:
-------------
The standard states that an empty t_fmt_ampm string indicates that the 12-hour format is not supported in the locale, but it is unclear how other related parts of the standard are affected in this case.

Notes to the Editor (not part of this interpretation):
-------------------------------------------------------
On page 160 line 5085 section 7.3.5.1 LC_TIME Locale Definition, change:
The operand shall consist of two strings, separated by a <semicolon>, each surrounded by double-quotes. The first string shall represent the ante-meridiem designation, the last string the post-meridiem designation.
to:
The operand shall consist of two strings, separated by a <semicolon>, each surrounded by double-quotes; the first string shall represent the ante-meridiem designation, the last string the post-meridiem designation. If and only if the 12-hour format is not supported in the locale, both strings shall be empty.


On page 160 line 5092 section 7.3.5.1 LC_TIME Locale Definition, change
If the string is empty, the 12-hour format is not supported in the locale.
to:
If and only if the 12-hour format is not supported in the locale, the string shall be empty.


On page 162 line 5150 section 7.3.5.2 LC_TIME C-Language Access, change:
    
AM_STR The appropriate ante-meridiem affix.


    PM_STR The appropriate post-meridiem affix.


    T_FMT_AMPM The appropriate time representation in the 12-hour clock format with AM_STR and PM_STR.
to:
AM_STR The appropriate ante-meridiem affix; if AM_STR and PM_STR are both empty strings, the 12-hour format is not supported in the locale.


    PM_STR The appropriate post-meridiem affix; if AM_STR and PM_STR are both empty strings, the 12-hour format is not supported in the locale.


    T_FMT_AMPM The appropriate time representation in the 12-hour clock format; if the 12-hour format is not supported in the locale, this shall be either an empty string or a string specifying a 24-hour clock format.


On page 266 line 8855 section <langinfo.h>, change:
a.m. or p.m. time format string.
to:
Time format string using 12-hour clock format, if supported in the locale; if the 12-hour format is not supported, this shall be either an empty string or a string specifying a 24-hour clock format.


On page 266 line 8856 section <langinfo.h>, change:
Ante-meridiem affix.
to:
Ante-meridiem affix; if AM_STR and PM_STR are both empty strings, the 12-hour format is not supported in the locale.


On page 266 line 8857 section <langinfo.h>, change:
Post-meridiem affix.
to:
Post-meridiem affix; if AM_STR and PM_STR are both empty strings, the 12-hour format is not supported in the locale.


On page 1020 lines 34774-34775 section getdate(), change:
The locale’s appropriate representation of time in AM and PM notation.
to:
The locale’s appropriate representation of time in 12-hour clock notation, if the 12-hour format is supported in the locale (see [xref to XBD 7.3.5.1]).


On page 2046 lines 65589-65590 section strftime(), change:
Replaced by the time in a.m. and p.m. notation; in the POSIX locale ...
to:
Replaced by the time in 12-hour clock notation; [CX]if the 12-hour format is not supported in the locale, this shall be either an empty string or the time in a 24-hour clock notation[/CX]. In the POSIX locale ...


On page 2064 line 66161 section strptime(), change:
12-hour clock time using the AM/PM notation if t_fmt_ampm is not an empty string in the LC_TIME portion of the current locale ...
to:
12-hour clock time, if the 12-hour format is supported in the locale (see [xref to XBD 7.3.5.1]) ...


On page 2474 line 79408 section at, change:
An AM/PM indication (one of the values from the am_pm keywords in the LC_TIME locale category) can follow the time
to:
If the LC_TIME category of the locale supports 12-hour time format (see [xref to XBD 7.3.5.1]), an AM/PM indication in the form of one of the values from the am_pm keywords in the LC_TIME locale category can follow the time


The following change is not needed if this bug is applied after bug 466 (which replaces the conversion specifiers with a reference to strftime()).
On page 2635 lines 85710-85711 section date, change:
12-hour clock time [01,12] using the AM/PM notation; in the POSIX locale ...
to:
12-hour clock time notation; if the 12-hour format is not supported in the locale, this shall be either an empty string or the time in a 24-hour clock notation. In the POSIX locale ...
(0004767)
ajosey (manager)
2020-02-03 21:14

Interpretation Proposed: 3 February 2020
(0004800)
ajosey (manager)
2020-03-23 15:24

Interpretation Approved: 23 March 2020

- Issue History
Date Modified Username Field Change
2019-12-18 15:35 geoffclare New Issue
2019-12-18 15:35 geoffclare Name => Geoff Clare
2019-12-18 15:35 geoffclare Organization => The Open Group
2019-12-18 15:35 geoffclare Section => 7.3.5.1 LC_TIME Locale Definition
2019-12-18 15:35 geoffclare Page Number => 160
2019-12-18 15:35 geoffclare Line Number => 5085
2019-12-18 15:35 geoffclare Interp Status => ---
2019-12-18 15:36 geoffclare Relationship added related to 0000081
2019-12-18 15:38 geoffclare Note Added: 0004688
2019-12-18 18:54 shware_systems Note Added: 0004689
2019-12-18 19:08 shware_systems Note Edited: 0004689
2020-01-30 16:57 Don Cragun Note Added: 0004762
2020-01-30 16:58 eblake Relationship added child of 0000466
2020-01-30 16:59 Don Cragun Interp Status --- => Pending
2020-01-30 16:59 Don Cragun Final Accepted Text => See Note: 0004762.
2020-01-30 16:59 Don Cragun Status New => Interpretation Required
2020-01-30 16:59 Don Cragun Resolution Open => Accepted As Marked
2020-01-30 16:59 Don Cragun Tag Attached: issue8
2020-02-03 21:14 ajosey Interp Status Pending => Proposed
2020-02-03 21:14 ajosey Note Added: 0004767
2020-03-23 15:24 ajosey Interp Status Proposed => Approved
2020-03-23 15:24 ajosey Note Added: 0004800
2020-05-05 15:08 geoffclare Status Interpretation Required => Applied
2024-06-11 09:08 agadmin Status Applied => Closed


Mantis 1.1.6[^]
Copyright © 2000 - 2008 Mantis Group
Powered by Mantis Bugtracker