Paul Eggert wrote: > Romain Lenglet <[EMAIL PROTECTED]> 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 _______________________________________________ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
