Hi Geoff,
I was already working with William to research XPG[234] behind the scenes.
Unfortunately, my copies of the various standards were in such condition
and organization that it was taking me more research time than might be
consumed by someone who has them neatly arranged in a bookshelf in their
office. Everything you related, plus some other details, I had already
found, but I had not sent mail to William describing POSIX.2, XPG2 and XPG3.
It did not occur to me that William might be getting impatient,
submitting to Mantis before "we" both understood where date_fmt
originated and whether it was necessary to change any standard. My
fault, not his.
The only reference to date_fmt I found in any standard related document
I possess is in the Tenth Unicode Conference Proceedings, which had a
non-normative example of a Solaris header file ((c) 1996) that describes
the LC_TIME options. It was obviously an extension that was added by
Sun Microsystems.
My present conclusion is that this Solaris extension has no place in the
POSIX standard, but I am continuing the research with William to find
out where he "discovered" date_fmt (such as, perhaps, Linux). It might
also be in the unpublished SVID-4 (which I think I have somewhere).
I will also be coaching William about the undocumented, arcane
procedures that we operate under in the Austin Group forum. We do not
make it easy for a new member to learn how we do our business.
Cheers,
Larry
On 5/26/2020 4:19 AM, Geoff Clare wrote:
======================================================================
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.
. . . deleted . . .
