GNU bug report logs -
#39693
Any chance of fixing --rfc-3339 to conform to the standard?
Previous Next
Full log
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
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
This bug report was last modified 5 years and 123 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.