On Thu, 8 Sep 2011 12:00:15 -0400, Ray Denenberg, Library of Congress wrote
> From: Edward C. Zimmermann
> > Imagine I want to document a date I know took place at the start of Dec.
> > 1990 but I'm not sure if it was the 1st, 2nd or 3rd of the month.. and
> > I
> > want to check.. The expression "1990-12-0u" seems fine and dandy...
> > later
> > when I've checked that it was the 3rd I'd fill it in.. That's why I
> > might
> > write "1990-12-0u" and not "1990-12"
> Yes, we understand, month vs. year precision. But you achieve month
> precision with "1990-12-uu".
No. Its an expression of day precision. The month is known and the day is
not yet announced but the difference between
is that the later is saying "the date is known (measurable) and shall be
supplied at a later time".
> And really, the actual theoretical precision
> you would want to achieve (for your example) is to narrow it to months 1-3,
> which "1990-12-0u" doesn't do anyway. "1990-12-0u" would match the
> you want only if your use case was "I know it was one of the first ten
> months." If you really had a practical use case where you know it was
> during the first ten months, then the argument for "1990-12-0u" would be
Week precision would probably be better, e.g. 1990-W50, but I don't want to
be a party pooper...
> > I would argue that u as blanks to be filled in.. should be allowed
> > wherever
> > anyone might see fit to use them. I personally might not ever see the
> > need
> > for an expression such as "uuu2-12-22" but who am I to say "no no"..?
> I thought there is general consensus that we don't want to be creating
> unecessary complexity by adding features that nobody has asked for but that
> someone might need someday.
Restricting where u can be used is "creating" complexity. If we just "u" as
a kind of wildcard in matching, I think, things get quite simple. The rule
should, I think, be "u" can be used anywhere where a digit is normally used,
in lieu of that digit. Sure many expression perhaps don't make semantic
sense, don't tell a good story, but I do not think its our job to define
narratives. While I might use "uuu2-12-22" I think its should be perfectly
OK to have such expressions... From an implementation perspective its less
effort to accept u anywhere than to have "rules". In contract to x
(precision masking where a <floating point, integer exponent> can be used to
internally store things) the u expression I think will always need to be
stored as strings... If someone can provide an alternative data storage
model.. and one will restrictions make sense.. I could change my mind.. but
as long as I think it'll be strings.. I see nothing to gain by adding more
> > > 3. Year and month specified, day unspecified (And similarly no
> > provision
> > for just one digit of the day unspecified, as in 1990-12-0u.)
> > Beware the use of the predicate "unspecified". In the date "1990"
> > neither
> > the month or day are specified but its something quite different from
> > "1990-
> > uu-uu". If one can specify the month of a date that is expressed in
> > years
> > then the date has at least month precision.. similarly if one specify
> > the
> > month and day it has day precision.. "can specify" and "specify" are
> > not, I
> > must stress, the same. With "1990-12-uu" I explicitly state that I "can
> > specify" the day but has not yet--- I plan on filling in the blanks..
> > With "1990-12" I say that I can't--- obviously with more information....
> Ok, I will try to tighten up the prose is this area.
Edward C. Zimmermann, NONMONOTONIC LAB