Re: date not parsing full iso-8601

[Nic Ferrier]

Paul Eggert <address@hidden> writes:

> Nic Ferrier <address@hidden> writes:
>
>> Curiously it seems to be the timezone that it doing it because this
>> DOES work:
>>
>>   $ date --date "2004-12-18T17:28:00"
>
> GNU date parsed the "T" as the military time zone "T".
>
> Adding support for more ISO date forms is on the list of things to do.
> It is nontrivial, for backward compatibility reasons.  In the mean
> time, if you stick to the forms described in the documentation, it
> should work.

Sorry, I must be being stupid because I thought I *was* sticking to
the forms in the documentation.


The GNU coreutils manual 5.6.1 (the info node was specified in my
original mail) says this:

   The output of `date' is not always acceptable as a date string, not
   only because of the language problem, but also because there is no
   standard meaning for time zone items like `IST'.  

   When using `date' to generate a date string intended to be parsed
   later, specify a date format that is independent of language and
   that does not use time zone items other than `UTC' and `Z'.  

   Here are some ways to do this:

There is then a list of some examples of dates generated by the date
command. Here is the list verbatim from the coreutils manual:

     $ LC_ALL=C TZ=UTC0 date
     Fri Dec 15 19:48:05 UTC 2000
     $ TZ=UTC0 date +"%Y-%m-%d %H:%M:%SZ"
     2000-12-15 19:48:05Z
     $ date --iso-8601=seconds  # a GNU extension
     2000-12-15T11:48:05-0800
     $ date --rfc-2822  # a GNU extension
     Fri, 15 Dec 2000 11:48:05 -0800
     $ date +"%Y-%m-%d %H:%M:%S %z"  # %z is a GNU extension.
     2000-12-15 11:48:05 -0800

Note the third item:

     $ date --iso-8601=seconds  # a GNU extension
     2000-12-15T11:48:05-0800

This is what I am reporting a bug about. It's not an additional
requirement, it's a mismatch between what the documentation says date
does and what date actually does.

Of course, I may have misunderstood the documentation. If so,
apologies.



Nic