On 23/10/15 03:39, Pádraig Brady wrote: > On 19/09/15 17:46, Michael Gold wrote: >> Package: coreutils >> Version: 8.23-4 >> Severity: minor >> >> The manual page for 'date' says --iso-8601 will "output date/time in ISO >> 8601 format", but I don't believe the format actually complies with that >> standard when a time is included. >> >> §4.3.3d says (http://dotat.at/tmp/ISO_8601-2004_E.pdf#): >> "the expression shall either be completely in basic format, in which >> case the minimum number of separators necessary for the required >> expression is used, or completely in extended format, in which case >> additional separators shall be used in accordance with 4.1 and 4.2." >> >> But --iso-8601=m uses extended format for the date and time, and basic >> format for the timezone. Since making the option actually use ISO 8601 >> format could break scripts, a note in the manual page is probably the >> best fix. E.g., >> "output date/time in ISO 8601 extended format, except for the time >> zone which will be output in basic format when a time is included and >> omitted otherwise" >> >> - Michael > > I agree with the above analysis. > I.E. the tz portion should contain a ':' like > 2015-10-23T01:49+01:00 > > Note date(1) can parse either basic or extended tz: > > $ date --date='2015-10-23T01:49+01:30' > Fri Oct 23 01:19:00 IST 2015 > > As can python's iso8601 module for example. > > I see the code in date uses %:z (extended format) for --rfc-3339 > but %z (basic format) for --iso-8601. That's because %:z support wasn't > added to gnulib's strftime until 2005, while the --iso-8601 option > was added in 1999. > > So there is the possibility of changing the output format > to conform to the standard. How likely is that to break things? > One possibility is that file names might be generated with > `date -Im`, but would even that be likely to break things? > > Attached is the change to date(1) to adjust the output format, > and if this is thought too risky, we can instead just > augment the info docs with Michael's comment above.
Pushed to coreutils upstream at http://git.sv.gnu.org/gitweb/?p=coreutils.git;a=commitdiff;h=v8.24-64-g17bbf6c
