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

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.

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.)

I generally am very receptive to arguments based on standards
compliance, but in this case, no way.

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

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

OK, so that's fine to always use hyphen-minus, which is always
available.