Subject: coreutils: date should support ISO-8601 / W3C time formats
Date: Thu, 18 Jan 2007 20:00:32 +0100
Package: coreutils
Version: 5.97-5.2
Severity: wishlist
The "date" command should support ISO-8601 / W3C time formats, both
as input (parsing) and output.
Note that the W3C format[1] (used in XML schema) is a particular form
of ISO 8601. There must be a ":" between the hours and the minutes in
the time zone designator. The old --iso-8601 option did not add one.
Moreover, still in output, 'Z' should be used instead of +00:00 or
-00:00 as this is the canonical representation in XML schema[2].
[1] http://www.w3.org/TR/NOTE-datetime
[2] http://www.w3.org/TR/xmlschema-2/#dateTime-timezones
-- System Information:
Debian Release: 4.0
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable')
Architecture: i386 (i686)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18-3-686-bigmem
Locale: LANG=POSIX, LC_CTYPE=en_US.ISO8859-1 (charmap=ISO-8859-1)
Versions of packages coreutils depends on:
ii libacl1 2.2.42-1 Access control list shared library
ii libc6 2.3.6.ds1-10 GNU C Library: Shared libraries
ii libselinux1 1.32-3 SELinux shared libraries
coreutils recommends no packages.
-- no debconf information
Subject: coreutils: Another comment regarding ISO 8601
Date: Mon, 16 Mar 2015 22:43:28 -0700
Package: coreutils
Version: 8.23-3
Followup-For: Bug #407476
ISO 8601 also requires that date offsets less than UTC (e.g. "−5:00") use a "−" ("minus sign" U+2212); not a "-" ("hyphen-minus" U+002D) as is printed.
Since they look identical in monospace fonts, very similar in variable-width fonts, and the "minus sign" is not easily typed on most keyboards, it is understandable why there would be confusion.
-- System Information:
Debian Release: 8.0
APT prefers testing
APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Kernel: Linux 3.16.0-4-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages coreutils depends on:
ii libacl1 2.2.52-2
ii libattr1 1:2.4.47-2
ii libc6 2.19-15
ii libselinux1 2.3-2
coreutils recommends no packages.
coreutils suggests no packages.
-- no debconf information
Acknowledgement sent
to Vincent Lefevre <[email protected]>:
Extra info received and forwarded to list. Copy sent to Michael Stone <[email protected]>.
(Tue, 17 Mar 2015 08:09:05 GMT) (full text, mbox, link).
Subject: Re: Bug#407476: coreutils: Another comment regarding ISO 8601
Date: Tue, 17 Mar 2015 09:04:32 +0100
On 2015-03-16 22:43:28 -0700, Grant Sanders wrote:
> ISO 8601 also requires that date offsets less than UTC (e.g.
> "−5:00") use a "−" ("minus sign" U+2212); not a "-" ("hyphen-minus"
> U+002D) as is printed.
That would be true only then the charset permits that. But also
since the date may be used in a context restricted to US-ASCII
for portability or other reasons, this should also be controlled
by an option (and I don't think that changing LC_CTYPE to "C" is
a right thing for the user since it would affect error messages
too.)
--
Vincent Lefèvre <[email protected]> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
Acknowledgement sent
to Michael Stone <[email protected]>:
Extra info received and forwarded to list.
(Tue, 17 Mar 2015 11:39:05 GMT) (full text, mbox, link).
Subject: Re: Bug#407476: coreutils: Another comment regarding ISO 8601
Date: Tue, 17 Mar 2015 07:25:49 -0400
I generally am very receptive to arguments based on standards
compliance, but in this case, no way.
On Mon, Mar 16, 2015 at 10:43:28PM -0700, you wrote:
>ISO 8601 also requires that date offsets less than UTC (e.g. "−5:00") use a "−" ("minus sign" U+2212); not a "-" ("hyphen-minus" U+002D) as is printed.
AFAICT ISO 8601 specifies "hyphen". I don't see that there is any
reference to unicode in the standard. Full disclosure: I'm not working
from an official document of record since ISO charges for their
standards.
I would be somewhat shocked to find a parser that accepted U+2212, and
flabbergasted to find one that did not accept U+002D.
I would be surprised if the standard did mandate a character that would
preclude the standard from being used in many contexts where it works
well today in plain ASCII.
If someone can actually show that ISO 8601 requires the hyphen to be a
non-ascii unicode character my course would likely be to simply document
non-compliance. Changing the character would break working systems.
Mike Stone
Acknowledgement sent
to Vincent Lefevre <[email protected]>:
Extra info received and forwarded to list. Copy sent to Michael Stone <[email protected]>.
(Tue, 17 Mar 2015 13:06:09 GMT) (full text, mbox, link).
Subject: Re: Bug#407476: coreutils: Another comment regarding ISO 8601
Date: Tue, 17 Mar 2015 14:03:17 +0100
On 2015-03-17 07:25:49 -0400, Michael Stone wrote:
> AFAICT ISO 8601 specifies "hyphen". I don't see that there is any reference
> to unicode in the standard. Full disclosure: I'm not working from an
> official document of record since ISO charges for their standards.
It seems that some general standards do not specify behavior related
to character sets, i.e. the mapping from the characters of the
standard to the actual characters depends on the implementation
or is specified somewhere else.
Here's what https://www.cs.tut.fi/~jkorpela/iso8601.html says:
The standard distinguishes the hyphen from the minus sign as well as
hyphen-minus, often called ASCII hyphen. (These concepts are explained
in the document [Dashes and hyphens].) However, it mentions that both
hyphen and minus may be mapped to hyphen-minus when the character
repertoire is limited, and this is common practice. Moreover, programs
that interpret date notations might expect to see hyphen-minus. In
principle, however, U+2010 HYPHEN is the most appropriate character
for use in ISO 8601 dates, when available (e.g., in text processing
when using a font that contains it).
So, I would say that both should be supported and controlled by an
option, for instance.
--
Vincent Lefèvre <[email protected]> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
Acknowledgement sent
to Michael Stone <[email protected]>:
Extra info received and forwarded to list.
(Tue, 17 Mar 2015 13:30:09 GMT) (full text, mbox, link).
Subject: Re: Bug#407476: coreutils: Another comment regarding ISO 8601
Date: Tue, 17 Mar 2015 09:28:11 -0400
On Tue, Mar 17, 2015 at 02:03:17PM +0100, Vincent Lefevre wrote:
>On 2015-03-17 07:25:49 -0400, Michael Stone wrote:
>> AFAICT ISO 8601 specifies "hyphen". I don't see that there is any reference
>> to unicode in the standard. Full disclosure: I'm not working from an
>> official document of record since ISO charges for their standards.
>
>It seems that some general standards do not specify behavior related
>to character sets, i.e. the mapping from the characters of the
>standard to the actual characters depends on the implementation
>or is specified somewhere else.
>
>Here's what https://www.cs.tut.fi/~jkorpela/iso8601.html says:
>
> The standard distinguishes the hyphen from the minus sign as well as
> hyphen-minus, often called ASCII hyphen. (These concepts are explained
> in the document [Dashes and hyphens].) However, it mentions that both
> hyphen and minus may be mapped to hyphen-minus when the character
> repertoire is limited, and this is common practice. Moreover, programs
> that interpret date notations might expect to see hyphen-minus. In
> principle, however, U+2010 HYPHEN is the most appropriate character
> for use in ISO 8601 dates, when available (e.g., in text processing
> when using a font that contains it).
>
>So, I would say that both should be supported and controlled by an
>option, for instance.
I have found a later unofficial version of the 8601, and it contains the
following which is the basis for your quoted paragraph: "In an
environment where use is made of a character repertoire based on ISO/IEC
646, “hyphen” and “minus” are both mapped onto “hyphen-minus”."
Which is exactly what we're doing already. I don't see any value in
trying to add options to support representations that nobody uses.
Mike Stone
Acknowledgement sent
to Vincent Lefevre <[email protected]>:
Extra info received and forwarded to list. Copy sent to Michael Stone <[email protected]>.
(Tue, 17 Mar 2015 14:03:05 GMT) (full text, mbox, link).
Subject: Re: Bug#407476: coreutils: Another comment regarding ISO 8601
Date: Tue, 17 Mar 2015 14:59:25 +0100
On 2015-03-17 09:28:11 -0400, Michael Stone wrote:
> I have found a later unofficial version of the 8601, and it contains the
> following which is the basis for your quoted paragraph: "In an environment
> where use is made of a character repertoire based on ISO/IEC 646, “hyphen”
> and “minus” are both mapped onto “hyphen-minus”."
>
> Which is exactly what we're doing already. I don't see any value in trying
> to add options to support representations that nobody uses.
OK, so that's fine to always use hyphen-minus, which is always
available.
--
Vincent Lefèvre <[email protected]> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
Debbugs is free software and licensed under the terms of the GNU General
Public License version 2. The current version can be obtained
from https://bugs.debian.org/debbugs-source/.