[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#39693: Sv: bug#39693: Any chance of fixing --rfc-3339 to conform to
Mads Bondo Dydensborg
bug#39693: Sv: bug#39693: Any chance of fixing --rfc-3339 to conform to the standard?
Fri, 21 Feb 2020 07:56:24 +0000
Your statement is in conflict with the message exchange, referenced by the bug
I linked to, with, as I understand it, the authors of the standard:
The date-time production in rfc-3339 clearly includes a literal "T".
All examples in rfc-3339 includes a T.
The ISO output from date can not be used, as it uses a "," as fractional
separator (which is preferred in ISO8601:2004), where rfc-3339 specifies a ".".
So, no dice, the output
is not a valid rfc-3339 datetime with fractionalparts.
It truly is a mess, IMHO, but adding T to the rfc-3339 output would, AFACIT,
make it conform to the ABNF in section 5.6 of rfc-3339, which can't be a bad
Fra: Paul Eggert <address@hidden>
Sendt: 20. februar 2020 17:16:43
Til: Mads Bondo Dydensborg
Emne: Re: bug#39693: Any chance of fixing --rfc-3339 to conform to the standard?
On 2/20/20 4:39 AM, Mads Bondo Dydensborg wrote:
> As have been established in 2006 and again in 2010, the rfc-3339 mandates the
> use of "T" in a single field timestamp.
No, RFC 3339 explicitly allows the use of space. It says:
NOTE: ISO 8601 defines date and time separated by "T".
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.
This paragraph was put into the RFC at my suggestion, precisely so that GNU
"date" output wouldn't have to contain that "T".
Tf you want GNU 'date' to output the 'T', you can use 'date --iso-8601=s'
instead of 'date --rfc-3339=s'. That's the point of having these two options for
GNU 'date'. If it weren't for this difference in behavior, GNU 'date' wouldn't
have needed a --rfc-3339 option in the first place, and we shouldn't change the
meaning of --rfc-3339 to eviscerate the whole point of the option.