coreutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Pádraig Brady
Subject: Re: Bug#799479: date --iso-8601=m does not use ISO 8601 format as documented
Date: Fri, 23 Oct 2015 03:39:08 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0

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.

thanks,
Pádraig.

Attachment: iso-8601-extended-tz.patch
Description: Text Data


reply via email to

[Prev in Thread] Current Thread [Next in Thread]