|Anonymous | Login||2020-09-27 23:11 UTC|
|Main | My View | View Issues | Change Log | Docs|
|Viewing Issue Simple Details|
|ID||Category||Severity||Type||Date Submitted||Last Update|
|0001345||[1003.1(2016/18)/Issue7+TC2] Shell and Utilities||Objection||Error||2020-05-24 22:48||2020-07-02 11:02|
|Name||J William Piggott|
|Page Number||163, 2634-2638|
|Line Number||5224-5228, 85673-85823|
|Final Accepted Text|
|Summary||0001345: date(1) default format|
For simplicity I will state XPG3 positions as fact, although I do not actually
have access to the XPG3 standard. The XPG3 references are not imperative to
addressing this issue, they merely give plausible explanation for the current
situation. Anyone with access to the XPG3 standard is welcome to confirm or
deny. Finally, I'm new here and will likely do something wrong; I plead for
patience and guidance, please.
default format: when calling date(1) without arguments.
There are two closely related issues for the date(1) default format:
a) the default format is ambiguous:
Stated: shall be the locale specific 'date and time'.
Not Stated: what locale element represents it.
By default, the current date and time shall be written.
... the [default format] output in the POSIX locale ...
EXAMPLES [also illustrate locale specific default formats]
b) the STDOUT POSIX locale format string is unreachable
Line 85807 date "+%a %b %e %H:%M:%S %Z %Y"
XPG3 specified the date(1) default output format as %C [uppercase 'C'].
It was bound to the date_fmt locale element:
%C locale’s date and time representation as produced by date(1)
When no formatting operand is specified, the output in the POSIX locale shall
be equivalent to specifying: date "+%a %b %e %H:%M:%S %Z %Y"
# date and time representation as produced by date(1) (%C)
# "%a %b %e %H:%M:%S %Z %Y"
date_fmt " ...
NOTE: the format in date(1) STDOUT was reachable via LC_TIME date_fmt; %C
In XPG4 %C was redefined to Century number and date_fmt was dropped from the
POSIX locale. However, the change seemed to overlook establishing a new date(1)
default format specifier and did not fix the dangling reference to the deleted
date_fmt in the date(1) STDOUT section.
The required default date(1) POSIX locale format being unavailable has lead to
implementation creativity. Glibc and coreutils have partially reimplemented the
XPG3 date_fmt as the default date(1) format without binding it to a format
specifier. There have been several posts to the glibc mailing list asking what
are the expected values for d_t_fmt and date_fmt. Nobody knows. I think the
reason date_fmt was reintroduced is to resolve the unreachable format string
the standard requires in the date(1) STDOUT section.
a) The de facto date(1) default format must be %c (LC_TIME d_t_fmt).
It is the only locale keyword that satisfies the required 'date and time'.
The several date(1) EXAMPLES seem to support this position.
b) date(1) STDOUT should not be restating the POSIX locale. It should
simply state %c, and let the POSIX locale speak for itself.
That leaves the conflict between the current format string listed in STDOUT
and the value for the POSIX locale d_t_fmt. I propose, that because common
date(1) implementations include %Z in the default output, (as the current
standard requires); it should be added to the POSIX locale's LC_TIME d_t_fmt
XBD Page 163
Section 220.127.116.11 LC_TIME Category in the POSIX Locale
Line 5224 replace with:
# "%a %b %e %H:%M:%S %Z %Y"
Line 5228 replace with:
XCU Page 2634
Section date DESCRIPTION
Lines 85673-85676 replace with:
The date utility shall write the date and time to standard output <XSI>or
attempt to set the system date and time.</XSI> By default, the current date and
time shall be written in the locale dependent %c format. If an operand
beginning with '+' is specified, the output format of date shall be controlled
by the conversion specifications and other text in the operand.
XCU Page 2637
Section date STDOUT
Lines 85805-85807 replace with:
The default standard output shall be in the locale dependent %c format(see
[xref to XSH 3 strftime()] and [xref to XBD 18.104.22.168 LC_TIME Category in the
XCU Page 2638
Section date APPLICATION USAGE
Lines 85821-85823 replaced with:
The default standard output may be difficult to parse, as it is locale
specific. It may contain <newline> characters and be vastly different from what
is defined for the POSIX locale.
|Tags||No tags attached.|
edited on: 2020-06-08 16:06
On systems that do not support the POSIX2_LOCALEDEF option, it is platform specific what the default formats are for any locales in addition to POSIX the platform makes available. As unspecified platform elections not modifiable by a user there would be no documentation requirement either. I suspect date_fmt was rejected because it constrained how a date utility for such a fixed set of locales might be written. Some implementations might just compile a table of format strings directly into the utility, for example, and not make any references to data setlocale() makes available to a process.
To keep this flexibiity when POSIX2_LOCALEDEF is supported means a platform has to document a) whether date only supports locales provided by the platform, and if so which format is used when a locale created by localedef is referenced; and if not b) the implementation-defined means of mapping a locale name that represents the output of localedef to the platform specific means of providing additional format strings. A platform may elect to extend localedef to accomplish this, others may leverage catget() or use a simple text file format.
Because of these variations I think the Desired Action is too limiting. Adding an LD sensitive documentation requirement is more backwards compatible, I feel.
edited on: 2020-07-02 12:02
The POSIX locale default date utility format:
%a %b %e %H:%M:%S %Z %Ycontains two pieces of information beyond the minimum of date and time required for other locales: the day name (%a) and the time zone (%Z). Most implementations include these in the default date output for their implementation-provided locales.
Since many users would expect to see day name and time zone information in the default date output (particularly if they are used to the traditional behaviour that was standardised for the POSIX locale), as a minimum we should add something to APPLICATION USAGE about this. We should also consider recommending that implementations include them (either via "should" in normative text or a statement in RATIONALE). Here is a suggested set of changes that does the latter...
On page 2638 line 85823 section date, add a paragraph to APPLICATION USAGE:
Since the default date utility format for locales other than the POSIX or C locale is not required to include anything beyond the date and time, whereas for the POSIX or C locale it also includes the day name and time zone, it may be necessary to specify a format (or override the locale-selection environment variables) to ensure this information is included when desired.
On page 2640 line 85914 section date, add these paragraphs to RATIONALE:
Although this standard only requires the default date utility format, for locales other than the POSIX or C locale, to include the date and time, it is common for implementations to include day name and time zone information as well. (For the POSIX locale this is required, with the day name in %a format at the beginning and the time zone in %Z format before the year.) Implementations are encouraged to include the day name (in %a or %A format) and the time zone (in %Z or %z format) in the default date utility format for all of the locales they provide.
|For the record, most of the historical information given in the Description of this bug is factually incorrect. See the mailing list for details.|
|2020-05-24 22:48||j_willie||New Issue|
|2020-05-24 22:48||j_willie||Name||=> J William Piggott|
|2020-05-24 22:48||j_willie||Section||=> date|
|2020-05-24 22:48||j_willie||Page Number||=> 163, 2634-2638|
|2020-05-24 22:48||j_willie||Line Number||=> 5224-5228, 85673-85823|
|2020-06-08 14:49||shware_systems||Note Added: 0004886|
|2020-06-08 16:06||shware_systems||Note Edited: 0004886|
|2020-07-02 10:57||geoffclare||Note Added: 0004893|
|2020-07-02 11:02||geoffclare||Note Added: 0004894|
|2020-07-02 12:02||geoffclare||Note Edited: 0004893|
|Mantis 1.1.6[^] Copyright © 2000 - 2008 Mantis Group|