[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#39693: Any chance of fixing --rfc-3339 to conform to the standard?

From: Mads Bondo Dydensborg
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:

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 %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?


Mads Bondo Dydensborg

reply via email to

[Prev in Thread] Current Thread [Next in Thread]