Syd - again, thanks for the comments.
From: Syd Bauman
> * "The characters '?' and '~' apply either to the entire portion of
> the string to their left, unless": but they don't apply to the
> entire *string* to their left, only to the *date*, *time*, or
> *dateTime*, right? (See 103 and 205.)
I changed "string" to "date-string"
> * "another component of ... of that component.": there are no
> examples of this, which makes me nervous. Does it mean that the "~"
> in (2011)-06-04~ only applies to the "-06-04" part?
A better example would be '(2011)?-06-04~' in which the "~" only applies to
the "-06-04" part.
However, '(2011)-06-04~' would be interpreted to mean that "~" only applies
to the "-06-04" part, but it would be better expressed as '2011-(06-04)~'.
I've added examples for this.
> * "'?' and '~' apply to a year, month, day, year-month, month-day, or
> year-month-day. ...": why on earth would they not be applicable to
> the hour, minute, second, hour-minute, minute-second, or
Because nobody expressed a need.
> What is the difference between masked precision and unspecified?
I have added a note:
In feature "Masked Precision" '196x' is said to have "decade precision". In
contrast, '196u' has year precision. Both represent a year during the 1960s,
but for 196x the year isn't given because it is known only with decade
precision. For 196u the year isn't given for reasons that are not specified
but there is some expectation (though no guarantee) that the year may be
supplied later; for 196x there is no such expectation.
> It may be useful to express these as equivalents of some sort:
> 196x = 1960-01-01/1969-12-31
> or whatever.
No, 196x is not intended to represent an entire decade, but rather a single
year (with decade precision).
> This seems a bit silly to me. The "yyyy-mm-dd" pattern makes no sense
> in some other calendars.
The need was expressed to be able to specify a calendar, and so this is the
way to do it. How this feature will be used is up to those who requested the
feature to figure out, this has not been developed whatsoever beyond this
simple ability to specify a calendar name, and it may never be. And if it
is, only a date of the form yyyy-mm-dd which is meaningful in some other
calendar would be compatible with this spec (and that assumes that some
vocabular for calendar names is recognized) and to accommodate dates of a
different form, the spec will need to be enhanced. This is all left for
> As I've said before, I think 104 should be moved here to L2, or, better
> by far, both 104 and 208 should be dropped. A reasonable use case for
> years > 4 digits is *extremely* rare, and is completely impossible in
We want astronomers to be able to use this spec too.
> This, along with 207 and most of the possible future features, should
> probably be avoided.
But again this is a requested feature. It is anticipated that communities
will develop vocabularies for seasonal profiles and these could be specified
> I presume that whitespace is not permitted in any of these notations.
Right, I added a note.