Re: Bug#799479: date --iso-8601=m does not use ISO 8601 format as documented

[Pádraig Brady]

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