Re: bug in date: --rfc-3339=seconds and --rfc-3339=ns options do *not* output timestamps in RFC 3339 format

[Romain Lenglet]

Paul Eggert wrote:
> Romain Lenglet <address@hidden> writes:
> > "ISO 8601 states that the "T" may be omitted under some
> > circumstances.
>
> Omitted, not replaced by a space.

OK, you're right.

> ISO 8601 section 4.4 is 
> quite clear: it states "The space character shall not be used
> in the representations."

OK. And the NOTE in section 5.4.1 is clear also.

> RFC 3339 is equally clear: it says 
> "Applications using this syntax may choose, for the sake of
> readability, to specify a full-date and full-time separated by
> (say) a space character." Which is exactly what GNU date is
> doing.

This interpretation of the NOTE in section 5.6 is not shared by 
everyone. e.g. cf. 
http://validator.w3.org/feed/docs/error/InvalidRFC3339Date.html
http://lists.infodrom.org/infodrom-sysklogd/2003/0023.html

And in this NOTE, replacing "T" by a space is only one example 
("(say)"). This NOTE then allows to replace "T" by *(say)* an 
underscore. How will you parse that? If one follows this, for 
the sake of readability, one can specify a full-date and 
full-time separated by *(say)* just anything. How would you 
parse the "just anything" that anyone seems to be allowed to use 
by this NOTE?

Since this NOTE is ambiguous ("SHOULD" in the beginninig of 
section 5.6, and the ABNF makes "T" mandatory, but in this 
NOTE: "may", "(say)"), let's stick to the ABNF, which makes 
the "T" mandatory. It is the safest bet.


Even when considering that replacing "T" with a space seems to be 
allowed by this NOTE in RFC 3339, making "T" mandatory seems to 
be the general consensus:
- XMLSchema's dateTime type conforms to RFC 3339, except that it 
makes the timezone optional, and allows for time "24:00:00", and 
it makes "T" mandatory.
- The Atom standard (RFC 4287) uses RFC 3339, but makes the "T" 
explictly mandatory.
- W3C's datetime format (another profile of ISO 8601, similar to 
RFC 3339) makes the "T" mandatory:
http://www.w3.org/TR/1998/NOTE-datetime-19980827

I know that you seem to have problems parsing this "T", but I 
don't agree that this is a good enough reason for not outputing 
a format that follows the (IMHO) general consensus.

Could you point me to other discussions or standards which allow 
to replace "T" with anything else? (except GNU date, of course)

> What real-world need is driving this bug report?

None. I was surprised that --rfc-3339=seconds does not follow the 
consensus. And using "T" instead of a space is more convenient 
when generating filenames with a timestamp, because it can 
easily be selected with the mouse by double-clicking on the 
screen. ;-)

> Would this 
> need be satisfied by the following command instead?
>
> date -u +'%Y-%m-%dT%H:%M:%SZ'

Yes. I am using this command. Well,
date -u +'%Y-%m-%dT%H:%M:%S%:z'
to be correct.

> This command generates ISO-8601-conforming time stamps on any
> POSIX-conforming host.  It's far more standard than anything
> else that's been proposed on this thread.
>
> Even if we were inclined to put in the "T", your two-line
> patch would be incorrect, since it doesn't change the
> documentation to match the behavior.

Sorry, I didn't think about the documentation.

> And the patch also 
> breaks the round-trip property guaranteed by the current
> documentation.  Fixing this would be nontrivial.

Allright. Then remove the --rfc-3339 option. It's fine with me.
Sorry, I won't send you a patch for this, because this one would 
be more than 10 lines.


Regards,

-- 
Romain LENGLET