> ====================================================================== > https://www.austingroupbugs.net/view.php?id=1345 > ======================================================================
> Summary: 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. If you weren't sure whether your assumptions about what was in XPG3 were true, it would have made sense to ask on the mailing list for confirmation, before committing them as assumed "fact" to a Mantis bug. I'm afraid that your assumptions were wrong - details below. > 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 None of the above is true. There was no %C format in XPG3's date. There was no STDOUT section in XPG3 utility man pages. The output format for date with no argument was not specified in XPG3, even for the POSIX locale. There were no "locale keywords" at all in XPG3. The closest thing it had to that was nl_langinfo() - which had D_T_FMT, D_FMT and T_FMT. > _______________ > 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. %C was new in XPG4 (via POSIX.2-1992). There was never a standard date_fmt. The STDOUT section (new in XPG4) specified the default output format for the POSIX locale as "%a %b %e %H:%M:%S %Z %Y". (This requirement also came from POSIX.2-1992.) > _______________________________________ > 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. I believe that leaving the default format unspecified, except for the POSIX locale, was intentional. The same approach was taken for many other utilities whose behaviour is affected by locale settings. > _______________________________________ > 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'. Absolutely not. The default output for the POSIX locale is not the same as %c and never has been. There is zero chance of this being changed. Even requiring it to be the same as %c for other locales would, I think, not achieve consensus as it would force many implementations to change for no good reason. > The several date(1) EXAMPLES seem to support this position. None of the examples show what the output from "date +%c" would be, so I don't see how they support making the default the same as %c. > 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. There is nothing wrong with the current requirements for the POSIX locale, and no reason to change them. They match long standing existing practice. The only potential for change that I see is to add a date_fmt locale keyword. For the POSIX locale this would be required to have the value "%a %b %e %H:%M:%S %Z %Y"; for other locales, implementations would naturally set it to match their current default format for the date utility. (For some, this might amount to just "%c" but there should be no requirement for this.) -- Geoff Clare <g.cl...@opengroup.org> The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
