My apologies for having been away so long, and for not having kept up
with the conversation. I have a vague recollection, though, that
someone posted a request for comments by today. So I'm going to go
through the specification and post comments today, even though I don't
have time to read the conversations I've missed. So please forgive me
if I head down paths already tread thoroughly.
The rules need to be clearer about zone offsets. Not clear to me what
"Either format may be used" means. My suggestion would be to stick to
ISO 8601 extended, and *not* to permit the basic format. (Extended
has a colon iff minutes are present, basic does not.) (And note that
"Z" is not an alternate format: ISO 8601:2004 does not permit
"+00:00" or "-00:00" AFAIK.)
So I'd end the rules at the semicolon, and add a note:
ISO 8601 extended format time zone designation consists of either
a "Z" to indicate UTC, or a "+" (ahead of UTC) or "-" (behind
UTC) followed by a 2-digit hour, followed optionally by a colon
and the 2-digit minutes.
Insert "endpoint" between "Either" and "may be".
* The word being defined is capitalized in all cases except
* Is the explanation of the assumed model needed? Why not just "the
source for a particular date is dubious."?
* It would be useful, IMHO, to add examples to #3 and #4 in the list
in the Syntax/rules column.
* Why not unspecified month with known year and day? (Actually
happens to us occasionally in a diary -- fictional example: it says
"6th", so we know the day is 06; it says "Sarah told me ...", and
we know Sarah was only visiting in 1732; but the month is
unspecified, and while we may be able to figure it out someday ...)
* The short explanatory blurbs after some of the examples in
"Examples" column are quite useful; I think all of the examples
should have one.
* It is probably worth repeating in the "Syntax/rules" column that an
interval is represented by two "dates" separated by a solidus (aka
I am very glad to see that expressions of years with > 4 digits
is unambiguously indicated with a preceding 'y'. I presume, though,
that you cannot be convinced to completely remove this syntax from
the specification (else it would have already been removed given the
strong arguments for doing so previously put forth).
Can I at least convince you to move it to level 2? Remember that if
you want this to get any traction at all, people have to write
software to at least validate expressions, if not process them. Every
syntax you add makes it harder to write that software. So
introduction of a syntax is a cost/benefit analysis. In this case,
the cost is not particularly high, but the benefit is infinitesimally
So let's at least move the trouble of writing code that will
basically never get used to those doing a lot of work already,
The subsection "Sorting Seasons" is not about sorting seasons, but
rather is about sorting LOC extended dates altogether. I think the
subsection here should just talk about seasons, and refer the reader
to an entire section elsewhere on ordering in general:
For ordering purposes, seasons may be sorted with Spring < Summer <
Autumn < Winter. However, the relationship between a season and a
date is not determined by this specification. Thus "2011-21" should
sort before "2011-23", but applications may choose to sort "2011-21"
and "2011-10" either way, or consider them incomparable. For a
complete discussion of the order relationship among LOC date and
time representations, see XXXX.
That section on order relations may be thorny, though.
But if the current wording is kept, there is an extraneous space
between "thus the value '" and "2000', for purposes".
Will try to take a look at level 2 and the BNF after lunch.