Paul Eggert <[EMAIL PROTECTED]> writes: > Nic Ferrier <[EMAIL PROTECTED]> 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 _______________________________________________ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils