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

Previous Next

Full log

View this message in rfc822 format

From: Mads Bondo Dydensborg <mabd <at> dbc.dk>
To: 39693 <at> debbugs.gnu.org
Subject: bug#39693: 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

Previous Next

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