On Sun, 21 Jun 2020, shwaresyst wrote:
Re: Are not the examples demonstrating relevant date utility specification
requirments as follows:
No, they are examples of how the various specified elements can produce output
reflecting various locale LC_TIME settings, that's all. The actual format
string is still an unspecified implementation election, not requirement. The
Description leaves open an implementation can elect to use %c for all locales,
but to keep backwards compatibility can't make this a requirement.
It was not my intent to require the use of %c. The recent addition to
the draft states formatting 'as if by strftime()', so use of its
specifiers would also be optional. I do acknowledge that my original
Desired Action language does make it required and needs to be changed.
My intent was to:
* clarify that the default output is the locale's date and time
* shine light on a practical implementation path within the standard's
framework by use of strftime() %c
Perhaps something like:
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"; for
Non-POSIX locales the output shall be the locale's date and time as if
by strftime() %c.
(there is a second half to the defect where I attempt to get the POSIX
STDOUT and d_t_fmt in alignment; but lets discuss one piece at a time)
What can be done, if someone wants to implement it, is add a switch, say "-c",
that does use %c instead of any default, and then portable code can be written that
examines LC_TIME data for guiding a parse of the utility's output. Then an enhancement
request to require that new switch can be drafted.
On Sunday, June 21, 2020 J William Piggott <elseift...@gmx.com> wrote:
On Fri, 5 Jun 2020, Geoff Clare wrote:
J William Piggott <elseift...@gmx.com> wrote, on 05 Jun 2020:
On Tue, 26 May 2020, Geoff Clare wrote:
======================================================================
https://www.austingroupbugs.net/view.php?id=1345
======================================================================
Summary: date(1) default format
... >8
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.
Lets address one step at a time as to why I suggest that.
What are these examples demonstrating that is relevant to the standards'
definition?:
85867 $ date
85868 Tue Jun 26 09:58:10 PDT 1990
The required output, when no format is specified, in the POSIX locale
(presumably with TZ=PST8PDT)
85875 $ LANG=da_DK.iso_8859−1 date
85876 ons 02 okt 1991 15:03:32 CET
As per the line above it, this is example output with a locale for
Denmark, when no format is specified, on an implementation where the
default date and time format for the selected locale is
"%a %d %b %Y %T %Z".
It does not imply that this is the correct or expected output when
using a locale for Denmark, only that this is what you would likely
get *if* the default format for the locale is "%a %d %b %Y %T %Z".
Nor does it imply anything about how the implementation decides
what default format to use for that locale.
85882 $ LANG=De_DE.88591 date
85883 Mi 02.Okt.1991, 15:01:21 MEZ
Likewise for Germany if the default format is "%a %d. %h. %Y, %T %Z".
85888 $ LANG=Fr_FR.88591 date
85889 Mer 02 oct 1991 MET 15:03:32
Likewise for France if the default format is "%a %d %h %Y %Z %T".
So, for examples 2, 3, and 4 your answer to my question is: nothing?
Are not the examples demonstrating relevant date utility specification
requirments as follows:
85674 By default, the current date and time shall be written.
85785 The following environment variables shall affect the execution of date:
85786 LANG
--
Geoff Clare <g.cl...@opengroup.org>
The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
