> Date: Sat, 26 Oct 2013 18:16:50 +0059
> From: Jason McIntyre <[email protected]>
>
> hi!
>
> further to another discussion on tech, i'm looking to document those
> options which posix say we should, but we do not. it should be only for
> a very small number of utilities, and pretty straightforward (famous
> last...)
>
> anyway, i wanted to post the date(1) part since it's a bit more
> controversial. posix lists this format as an xsi extension:
>
> mmddhhmm[[cc]yy]
>
> however we support this format:
>
> [[[[[cc]yy]mm]dd]HH]MM[.SS]
>
> just posting in case i've horribly misunderstood something. i'll commit,
> barring objection.
I have to disagree with this change. It sounds too much like we're
making excuses. The XSI extensions are not really part of POSIX.
They're just part of the recent POSIX documents because X/Open and
POSIX were merged. X/Open has always bean biased towards System V,
and one of thereasons why the XSI extension option exists in the
current joint standard is that X/Open sometimes conflicts with
traditional BSD behaviour.
So a better way to document this would be to say that we don't support
the XSI extension format
mmddhhmm[[cc]yy]
and instead supports the traditional BSD format
[[[[[cc]yy]mm]dd]HH]MM[.SS]
which is obviously superior.
Cheers,
Mark
> Index: date.1
> ===================================================================
> RCS file: /cvs/src/bin/date/date.1,v
> retrieving revision 1.59
> diff -u -r1.59 date.1
> --- date.1 31 Aug 2011 08:48:40 -0000 1.59
> +++ date.1 26 Oct 2013 17:09:59 -0000
> @@ -224,6 +224,14 @@
> The flags
> .Op Fl adjrtz
> are extensions to that specification.
> +.Pp
> +The order of the components of the argument
> +.Dq ccyymmddHHMM.SS
> +differs between this implementation and
> +.St -p1003.1-2008 .
> +In fact the standard does not recognise the
> +.Dq SS
> +component at all.
> .Sh HISTORY
> A
> .Nm
