Austin Group Defect Tracker

Aardvark Mark IV

Main | My View | View Issues | Change Log | Docs
  

Viewing Issue Simple Details [ Jump to Notes ] [ Issue History ] [ Print ]
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-12-16 15:27
Reporter j_willie View Status public  
Assigned To
Priority normal Resolution Accepted As Marked  
Status Applied  
Name J William Piggott
Organization
User Reference
Section date
Page Number 163, 2634-2638
Line Number 5224-5228, 85673-85823
Interp Status ---
Final Accepted Text Note: 0004893
Summary 0001345: date(1) default format
Description PREFACE
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.

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

   Line 85674:
    By default, the current date and time shall be written.
   Line 85805:
    ... the [default format] output in the POSIX locale ...
   Lines 85864-85892
    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"

PLAUSIBLE EXPLANATION
_______________________________________
XPG3

XPG3 specified the date(1) default output format as %C [uppercase 'C'].
     It was bound to the date_fmt locale element:

date(1)
%C locale’s date and time representation as produced by date(1)

STDOUT
 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"

POSIX Locale
# 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
_______________
XPG4

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.
_______________________________________
IMPACT
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.
_______________________________________
SOLUTION

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
   value.
Desired Action XBD Page 163
Section 7.3.5.3 LC_TIME Category in the POSIX Locale
Line 5224 replace with:
# "%a %b %e %H:%M:%S %Z %Y"

Line 5228 replace with:
<space><percent-sign><Z><space><percent-sign><Y>"

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 7.3.5.3 LC_TIME Category in the
POSIX Locale]).

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 tc3-2008
Attached Files

- Relationships

-  Notes
(0004886)
shware_systems (reporter)
2020-06-08 14:49
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.
(0004893)
geoffclare (manager)
2020-07-02 10:57
edited on: 2020-07-02 12:02

 The POSIX locale default date utility format:
%a %b %e %H:%M:%S %Z %Y
contains 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.

Some implementations have a date_fmt locale keyword (see [xref to XBD 7.3.5]) as an extension, to specify the default date utility format for each locale. On such implementations, if the localedef utility is used to create a locale that does not have this information, the date utility must by default still produce output for that locale that includes both the time and the date.
(0004894)
geoffclare (manager)
2020-07-02 11:02

 For the record, most of the historical information given in the Description of this bug is factually incorrect. See the mailing list for details.

- Issue History
Date Modified Username Field Change
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
2020-12-03 16:17 geoffclare Interp Status => ---
2020-12-03 16:17 geoffclare Final Accepted Text => Note: 0004893
2020-12-03 16:17 geoffclare Status New => Resolved
2020-12-03 16:17 geoffclare Resolution Open => Accepted As Marked
2020-12-03 16:17 geoffclare Tag Attached: tc3-2008
2020-12-16 15:27 geoffclare Status Resolved => Applied

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