Bug#354799: coreutils: date --iso-8601 not mentioned in the man page

[Kai Hendry]

Package: coreutils
Version: 5.93-5
Severity: normal

frodo$ zgrep 8601 *
changelog.gz: date --iso-8601=ns generates acceptable dates; it doesn't yet.
changelog.gz: For %s, use ISO 8601, and mention handling of leap seconds.
changelog.gz: (Options for date): Describe new --iso-8601=ns option.
NEWS.gz: `date' has a new option --iso-8601=ns that outputs
NEWS.gz: - `date -I' is no longer supported. Instead, use `date --iso-8601'.
frodo$ pwd
/usr/share/doc/coreutils

What's happened to iso-8601 in the man page?

-- System Information:
Debian Release: testing/unstable
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: i386 (i686)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.15-1-686
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)

Versions of packages coreutils depends on:
ii libacl1 2.2.34-1 Access control list shared library
ii libc6 2.3.6-1 GNU C Library: Shared libraries an
ii libselinux1 1.28-4 SELinux shared libraries

coreutils recommends no packages.

-- no debconf information

--
To UNSUBSCRIBE, email to debian-bugs-...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

[Bob Proulx]

Kai Hendry wrote:
> What's happened to iso-8601 in the man page?

As of upstream coreutils 5.90 the NEWS says:

date accepts the new option --rfc-3339=TIMESPEC. The old --iso-8602 (-I)
option is deprecated; it still works, but new applications should avoid it.
date, du, ls, and pr's time formats now support new %:z, %::z, %:::z
specifiers for numeric time zone offsets like -07:00, -07:00:00, and -07.

Bob

[Kai Hendry]

On 2006-03-21T09:39-0700 Bob Proulx wrote:
> Kai Hendry wrote:
> > What's happened to iso-8601 in the man page?
> As of upstream coreutils 5.90 the NEWS says:
> date accepts the new option --rfc-3339=TIMESPEC. The old --iso-8602 (-I)
> option is deprecated; it still works, but new applications should avoid it.

Why should I avoid it?

> date, du, ls, and pr's time formats now support new %:z, %::z, %:::z
> specifiers for numeric time zone offsets like -07:00, -07:00:00, and -07.

I didn't know about `pr`.

I am a big fan boy of iso-8601 and I've implemented it in several of my
projects. Has rfc-3339 superseded iso-8601?

http://www.rfc-archive.org/getrfc.php?rfc=3339 mentions rfc-3339 being
a profile of iso-8601. Whatever that means.

Lets compare. Iso8601 has no whitespace and it's shorter.

sam$ date --iso-8601=seconds
2006-03-22T12:33:45+0900

sam$ date --rfc-3339=seconds
2006-03-22 12:33:31+09:00

[Bob Proulx]

Kai Hendry wrote:
> Bob Proulx wrote:
> > Kai Hendry wrote:
> > > What's happened to iso-8601 in the man page?
> > As of upstream coreutils 5.90 the NEWS says:
> > date accepts the new option --rfc-3339=TIMESPEC. The old --iso-8602 (-I)
> > option is deprecated; it still works, but new applications should avoid it.
>
> Why should I avoid it?

Deprecated options may be removed in future versions of the command.
Applications that use deprecated options may stop working at some time
in the future when those options are no longer implemented.

> I am a big fan boy of iso-8601 and I've implemented it in several of my
> projects. Has rfc-3339 superseded iso-8601?

I think a fair paraphrase of the discussion was that instead of trying
to make the problematic iso-8601 work the decision was to switch to
rfc-3339 which was cleaner and avoided the worst of the problems.

The upstream discussion actually spanned several months. Here are the
pointers to the lead message in each of the months in the archive.

http://lists.gnu.org/archive/html/bug-coreutils/2005-05/msg00098.html
http://lists.gnu.org/archive/html/bug-coreutils/2005-07/msg00183.html
http://lists.gnu.org/archive/html/bug-coreutils/2005-09/msg00056.html

Bob

[Kai Hendry]

On 2006-03-21T23:16-0700 Bob Proulx wrote:
> I think a fair paraphrase of the discussion was that instead of trying
> to make the problematic iso-8601 work the decision was to switch to
> rfc-3339 which was cleaner and avoided the worst of the problems.
>
> The upstream discussion actually spanned several months. Here are the
> pointers to the lead message in each of the months in the archive.
>
> http://lists.gnu.org/archive/html/bug-coreutils/2005-05/msg00098.html
> http://lists.gnu.org/archive/html/bug-coreutils/2005-07/msg00183.html
> http://lists.gnu.org/archive/html/bug-coreutils/2005-09/msg00056.html

Thanks you for taking the time to answer me. Very interesting! The
optional 'T' seemed to throw a spanner into the works.

You can close this bug as far as I'm concerned.