bugGNU Core Utilities - Bugs: bug #11290, "date" cannot parse its...

 
 

You are not allowed to post comments on this tracker with your current authentication level.

bug #11290: "date" cannot parse its own ISO 8601 output

Submitter:  None
Submitted:  Fri 10 Dec 2004 12:38:45 PM UTC
   
 
Category:  None Severity:  3 - Normal
Item Group:  None Status:  Wont Fix
Privacy:  Public Assigned to:  None
Open/Closed:  Closed

Sat 08 Mar 2008 09:54:48 AM UTC, comment #3: 

Thanks for the suggestion, but I don't see sufficient justification for a change, now.

Jim Meyering <meyering>
Group administrator
Thu 21 Jul 2005 06:14:04 PM UTC, comment #2: 

Here's another possible patch to address this issue: until the format with the `T' is recognized properly, remove the `T' from the output. The `T' is optional anyway, according to ISO 8601:

(From http://www.cl.cam.ac.uk/~mgk25/iso-time.html)

If a date and a time are displayed on the same line, then always write the date in front of the time. If a date and a time value are stored together in a single data field, then ISO 8601 suggests that they should be separated by a latin capital letter T, as in 19951231T235959.

--- date.c.orig Thu Jul 21 11:07:53 2005
+++ date.c      Thu Jul 21 11:08:17 2005
@@ -482,10 +482,10 @@
   static char const * const iso_format_string[] =
   {
     "%Y-%m-%d",
-    "%Y-%m-%dT%H%z",
-    "%Y-%m-%dT%H:%M%z",
-    "%Y-%m-%dT%H:%M:%S%z",
-    "%Y-%m-%dT%H:%M:%S,%N%z"
+    "%Y-%m-%d %H%z",
+    "%Y-%m-%d %H:%M%z",
+    "%Y-%m-%d %H:%M:%S%z",
+    "%Y-%m-%d %H:%M:%S,%N%z"
   };
 
   if (format == NULL)

This seems preferable to having to resort to using tr(1) to filter out the `T', as Paul Eggert suggests.

Jos

Jos Backus <josb>
Thu 21 Jul 2005 04:37:48 PM UTC, comment #1: 

Here's a lame patch which makes this sort of work. It relies on the fact that the string "T" is lexed as a tZONE token in lookup_word(), and special-cases a date followed by a 'T' (actually, any tZONE, which is kinda bad) followed by a time in the grammar.

--- getdate.y.orig      Fri Dec 24 00:02:07 2004
+++ getdate.y   Wed Jul 20 22:57:06 2005
@@ -255,6 +255,12 @@
   | rel
       { pc->rels_seen++; }
   | number
+  | date tZONE time
+      {
+        pc->times_seen++;
+        pc->dates_seen++;
+      }
+

Jos

Jos Backus <josb>
Fri 10 Dec 2004 12:38:45 PM UTC, original submission:  

As shown in (1) below, date can produce valid ISO 8601 output. However, as shown in (2), it cannot parse that output. Even worse, as shown in (3), once the time zone information is removed, date interprets the "T" separator as a non-standard, undocumented and incompatible time zone specification. The "T" has to be replaced by a space before the output can be parsed acceptably, as shown in (4). So, the current behavior of date hinders the usage of ISO 8601 formatted dates in configuration and state text files.

(0)$ date --version
date (coreutils) 5.2.1
(1)$ date -Iseconds
2004-12-10T13:27:59+0100
(2)$ date -d "2004-12-10T13:27:59+0100"
date: invalid date `2004-12-10T13:27:59+0100'
(3)$ date -d "2004-12-10T13:27:59"
Fri Dec 10 07:27:59 CET 2004
(4)$ date -d "2004-12-10 13:27:59"
Fri Dec 10 13:27:59 CET 2004

Anonymous

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by meyering (Posted a comment)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

     

    Follow 2 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2008-03-08 meyering StatusNone Wont Fix
        Open/ClosedOpen Closed

    Back to the top

    Powered by Savane 3.13-d3ae.
    Corresponding source code