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)/Issue7+TC2] Base Definitions and Headers Comment Clarification Requested 2019-12-18 15:35 2019-12-18 18:54
Reporter geoffclare View Status public  
Assigned To
Priority normal Resolution Open  
Status New  
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 ---
Final Accepted Text
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 No tags attached.
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 

-  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.


- 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


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