|Anonymous | Login||2020-01-26 20:30 UTC|
|Main | My View | View Issues | Change Log | Docs|
|Viewing Issue Simple Details|
|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|
|Organization||The Open Group|
|Section||18.104.22.168 LC_TIME Locale Definition|
|Final Accepted Text|
|Summary||0001307: am_pm value in locales that do not distinguish between am and pm (again)|
The Notes to the Editor in the Interpretation response in bug 0000081 say:
Consider as a revision for a future edition, requiring that
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.
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.|
|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.|
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.
|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||=> 22.214.171.124 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|