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

2015-10-27 Thread 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

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

2015-10-22 Thread Pádraig Brady 
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.
From f8549660f20a3a394455a6f652ba6d167c1eb3cd Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?P=C3=A1draig=20Brady?= 
Date: Fri, 23 Oct 2015 03:19:18 +0100
Subject: [PATCH] date: use extended format timezone for --iso-8601

* src/date.c (main): Use %:z rather than %z with --iso-8601
as the standard states to consistently use extended format.
Note either format can be parsed by date.
* tests/misc/date.pl: Adjust accordingly.
* doc/coreutils.texi (du invocation): Clarify that "iso"
time styles are only similar to ISO-8601.
(ls invocation): Likewise.
(date invocation): Adjust the comment stating
that only --rfc-3339 output can be parsed by date(1).
* NEWS: Mention the change in behavior.
Reported at http://bugs.debian.org/799479
---
 NEWS   |  3 +++
 doc/coreutils.texi | 28 
 src/date.c |  8 
 tests/misc/date.pl |  8 
 4 files changed, 27 insertions(+), 20 deletions(-)

diff --git a/NEWS b/NEWS
index e771585..4780494 100644
--- a/NEWS
+++ b/NEWS
@@ -20,6 +20,9 @@ GNU coreutils NEWS-*- outline -*-
   base64 no longer supports hex or oct --wrap parameters,
   thus better supporting decimals with leading zeros.
 
+  date --iso-8601 now uses +00:00 timezone format rather than +.
+  The standard states to use this "extended" format throughout a timestamp.
+
   df now prefers sources towards the root of a device when
   eliding duplicate bind mounted entries.
 
diff --git a/doc/coreutils.texi b/doc/coreutils.texi
index 1b81daa..b1ba097 100644
--- a/doc/coreutils.texi
+++ b/doc/coreutils.texi
@@ -7498,8 +7498,8 @@ files; if you want output columns to line up, you may need to insert
 spaces in one of the two formats.
 
 @item full-iso
-List timestamps in full using ISO 8601 date, time, and time zone
-format with nanosecond precision, e.g., @samp{2002-03-30
+List timestamps in full using ISO 8601 like date, time, and time zone
+components with nanosecond precision, e.g., @samp{2002-03-30
 23:45:56.477817180 -0700}.  This style is equivalent to
 @samp{+%Y-%m-%d %H:%M:%S.%N %z}.
 
@@ -7509,14 +7509,14 @@ explain @command{make}'s behavior, since GNU @command{make}
 uses the full timestamp to determine whether a file is out of date.
 
 @item long-iso
-List ISO 8601 date and time in minutes, e.g.,
+List ISO 8601 like date and time in minutes, e.g.,
 @samp{2002-03-30 23:45}.  These timestamps are shorter than
 @samp{full-iso} timestamps, and are usually good enough for everyday
 work.  This style is equivalent to @samp{+%Y-%m-%d %H:%M}.
 
 @item iso
 List ISO 8601 dates for non-recent timestamps (e.g.,
-@samp{2002-03-30@ }), and ISO 8601 month, day, hour, and
+@samp{2002-03-30@ }), and ISO 8601 like month, day, hour, and
 minute for recent timestamps (e.g., @samp{03-30 23:45}).  These
 timestamps are uglier than @samp{long-iso} timestamps, but they carry
 nearly the same information in a smaller space and their brevity helps
@@ -11491,13 +11491,13 @@ with

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

2015-09-19 Thread Michael Gold 
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


-- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: arm64

Kernel: Linux 4.1.0-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages coreutils depends on:
ii  libacl1  2.2.52-2
ii  libattr1 1:2.4.47-2
ii  libc62.19-20
ii  libselinux1  2.3-2+b1

coreutils recommends no packages.

coreutils suggests no packages.

-- debconf-show failed


signature.asc
Description: Digital signature