GNU bug report logs - #39693
Any chance of fixing --rfc-3339 to conform to the standard?

Previous Next

To reply to this bug, email your comments to 39693 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Mads Bondo Dydensborg <mabd <at> dbc.dk>
To: "bug-coreutils <at> gnu.org" <bug-coreutils <at> gnu.org>
Subject: Any chance of fixing --rfc-3339 to conform to the standard?
Date: Thu, 20 Feb 2020 12:39:07 +0000

Hi there

As have been established in 2006 and again in 2010, the rfc-3339 mandates the use of "T" in a single field timestamp. This is currently not output by date (version 8.28)

Actual (example) output by "date --rfc-3339=ns"
2020-02-20 13:32:19.315773856+01:00
Expected output by above:
2020-02-20T13:32:19.315773856+01:00

There is a bug report here: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=6132, that established this as a bug. 
It seems requirements at the time was for at patch that could also parse the output with T, but as this output is 
a subset of ISO8601 (with T), this should be trivially fulfilled.

The change is trivial, I believe, including two tests.

Culprit code (from date.c in coreutils)

            static char const rfc_3339_format[][32] =
              {
                "%Y-%m-%d",
                "%Y-%m-%d %H:%M:%S%:z",
                "%Y-%m-%d %H:%M:%S.%N%:z"

Tests to be corrected (AFAICT):
     ['epoch-r', '--rfc-3339=sec -d @31536000',
      {OUT=>"1971-01-01 00:00:00+00:00"}],

     ['ns-10-r', '--rfc-3339=ns', '-d "1969-12-31 13:00:00.00000001-1100"',
      {OUT=>"1970-01-01 00:00:00.000000010+00:00"}],

     ['ns-max32-r', '--rfc-3339=ns', '-d "2038-01-19 03:14:07.999999999"',
      {OUT=>"2038-01-19 03:14:07.999999999+00:00"}],

Is there any chance for this to be fixed / a patch to be accepted? Or, would some other approach be sought to get this error in date fixed?

Br

Mads 
-- 
Mads Bondo Dydensborg

Message #8 received at 39693 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Mads Bondo Dydensborg <mabd <at> dbc.dk>
Cc: 39693 <at> debbugs.gnu.org
Subject: Re: bug#39693: Any chance of fixing --rfc-3339 to conform to the
 standard?
Date: Thu, 20 Feb 2020 08:16:43 -0800

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.

Message #15 received at 39693 <at> debbugs.gnu.org (full text, mbox):

From: Mads Bondo Dydensborg <mabd <at> dbc.dk>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: "39693 <at> debbugs.gnu.org" <39693 <at> debbugs.gnu.org>
Subject: Sv: bug#39693: Any chance of fixing --rfc-3339 to conform to the
 standard?
Date: Fri, 21 Feb 2020 07:56:24 +0000

Hi again


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:


https://debbugs.gnu.org/cgi/bugreport.cgi?msg=11;filename=rfc3339+is+the+T+mandatory%3F.eml;att=1;bug=6132


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

date --iso-8601=ns

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 thing.


Kind regards


Mads


________________________________
Fra: Paul Eggert <eggert <at> cs.ucla.edu>
Sendt: 20. februar 2020 17:16:43
Til: Mads Bondo Dydensborg
Cc: 39693 <at> debbugs.gnu.org
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.

Message #18 received at 39693 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Mads Bondo Dydensborg <mabd <at> dbc.dk>
Cc: 39693 <at> debbugs.gnu.org
Subject: Re: Sv: bug#39693: Any chance of fixing --rfc-3339 to conform to the
 standard?
Date: Fri, 21 Feb 2020 11:25:40 -0800

On 2/20/20 11:56 PM, Mads Bondo Dydensborg wrote:
> 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:

Not really. In that email exchange one of the authors of the RFC 
mentioned a goal of the RFC. The part of the RFC that I quoted, though, 
is an explicit exception to that particular goal. The RFC had several 
goals, they sometimes conflicted, and the RFC's text was a compromise. I 
was involved with the drafting of the RFC, and remember the history 
reasonably well.

> The ISO output from date can not be used, as it uses a "," as fractional separator

You can use the following if you want subsecond resolution with both 'T' 
and '.':

date '+%Y-%m-%dT%H:%M:%S.%N%:z'

This won't work for some historical timestamps (e.g., the Netherlands 
before 1937) but RFC 3339 doesn't support them anyway so it's probably 
good enough.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.