[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: bug in date: --rfc-3339=seconds and --rfc-3339=ns options do *not* o
From: |
Romain Lenglet |
Subject: |
Re: bug in date: --rfc-3339=seconds and --rfc-3339=ns options do *not* output timestamps in RFC 3339 format |
Date: |
Thu, 4 May 2006 15:25:16 +0900 |
User-agent: |
KMail/1.9.1 |
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