--- Begin Message ---
|
Subject: |
RFC 3339 misdescribed in doc of date(1) |
|
Date: |
Sat, 14 Jan 2017 16:21:17 +0000 |
The manual for version 8.26 of coreutils, in the section on date(1)'s
--rfc-3339 option, says of RFC 3339:
This is a subset of the ISO 8601 format, except that it also
permits applications to use a space rather than a `T' to separate
dates from times.
This description is not quite correct, in two respects.
Firstly, the formal syntax of RFC 3339 requires the "T" (of either case),
and does not permit a space. The bit about permitting a space is not
part of the official syntax; it is a suggestion that applications could
choose to use that non-standard top-level syntax while still using the
standard syntax for the date and time portions within it. Applications
inherently have that kind of usage choice, when presented with such a
collection of syntax pieces, so this isn't really a difference between
ISO 8601 and RFC 3339. Indeed, it was a common choice among users of
ISO 8601 before RFC 3339 came along. This also means that the formats
actually offered by --rfc-3339 don't strictly conform to RFC 3339.
Secondly, RFC 3339 does have an actual deviation from ISO 8601. When a
timezone with zero offset from UT is specified numerically, ISO 8601
requires it to be stated with a "+" sign, as "+00:00" (or "+00" or
"+0000"). RFC 3339 explicitly permits this to be specified with a "-"
sign, as "-00:00", which is forbidden by ISO 8601. (RFC 3339 adopts this
notation and its `unknown zone' connotation from RFC 2822, which doesn't
claim conformance to ISO 8601.) date(1) doesn't actually use this part
of RFC 3339, but the fact that it exists means that conformance to RFC
3339 doesn't imply conformance to ISO 8601. That's an issue for the
documentation's attempt to describe what conforms to what.
I suggest that the first two sentences of the --rfc-3339 doc should
change from
Display the date using a format specified by Internet RFC 3339.
This is a subset of the ISO 8601 format, except that it also
permits applications to use a space rather than a `T' to separate
dates from times.
to
Display the date using a format based on Internet RFC 3339,
which is nearly a subset of ISO 8601.
and furthermore the descriptions of the specific formats should be
annotated to discuss their conformance. "date" should say
This format conforms to both RFC 3339 and ISO 8601.
"seconds" and "ns" should say
The two main portions of the format each conform to both RFC 3339
and ISO 8601, but the standards require them to be combined with a
"T" separator, so this space separator does not conform.
-zefram
--- End Message ---
--- Begin Message ---
|
Subject: |
Re: bug#25448: RFC 3339 misdescribed in doc of date(1) |
|
Date: |
Sun, 15 Jan 2017 00:10:25 -0800 |
|
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 |
Your bug report raised two points: the numeric time zone -00, and separating
date from time with space instead of "T".
For -00, you're right that the documentation is messed up. While we're on the
topic, 'date' should output the numeric time zone '-00' when the time zone is
indeterminate. There's now a convention for indeterminate time zones in tzdb,
and 'date' should respect that.
For space instead of T, as it happens I contributed to the drafting of RFC 3339.
RFC 3339's note that allows a space instead of "T" was specifically put in with
usages like GNU "date" in mind. It's irrelevant whether this note is specified
in English or in EBNF: it's part of the spec. That being said, the documentation
could be worded more carefully.
The examples are intended to explain the GNU 'date' formats well enough that the
user shouldn't need detailed annotations or citations to chapter-and-verse of
the relevant standards. In rereading the documentation now, I see an opportunity
to streamline the wording a bit, to avoid a possible misinterpretation that the
coreutils documentation describes "the" ISO 6801 format (ISO 8601 does not
specify just one format) or "the" Internet RFC 3339 format (likewise).
While we're in the neighborhood, Internet RFC 2822 is now obsolete, and several
URLs in the coreutils manual either no longer work or have been superseded.
Instead of adding yet another option --rfc-5322 (will we keep adding more and
more?) I added an option --rfc-email that is intended to stand for the
latest-and-greatest Internet email date format.
I installed the attached patches to address all the issues that I found, which
should fix Bug#25448.
0001-build-update-gnulib-submodule-to-latest.patch
Description: Text Data
0002-maint-modernize-URLs.patch
Description: Text Data
0003-date-new-option-spelling-rfc-email.patch
Description: Text Data
0004-date-output-00-for-indeterminate-time-zone.patch
Description: Text Data
--- End Message ---