My motivation derives from the want, resp. need, for readability more coarse
than year, e.g. decade, "century", etc.
19xx I read as a date in the range 1900..1999 but with readability, resp.
precision, limited to a 100 year span just as 1999 is read as a date in the
range 1 Jan 1999 to 31 Dec 1999 with readability, resp. precision, limited
to a year. With this model was have a means to express implicit second,
minute, day, month, year, decade... precision.
Do we need something like 1x99? While a natural consequence of the syntax
its really something quite different. 1x99 has, for example, a precision of
year. Personally I don't think that I would implement it... at least not in
the near future.. While I can model x(s) from right to left via a
enumeration of precision 1999 read to decade is 199x or the 1990s, e.g.
the storage of "integers" for date, time and precision is sufficient a
date such as 1x99 would need a more work and have unless some trick pops
into my brain horrible performance.. and given my main applications are
search and retrieval.. performance matters A LOT.
Beyond all ot that.. I am not quite sure what x2x2 really means.. even if I
can construct it and compare dates...
On Mon, 27 Jun 2011 09:27:58 0400, Ray Denenberg wrote
> > From: [UTF8?]SaaÅ¡ha Metsärantala
>
> > In all the examples in #204, the x replaces the last digit of a year.
> > Is such a limitation part of the EDTF specification? Or should we
> > assume that x's may be placed on other digits anywhere in a date?
>
> As far as I recall (or can tell) there was only one advocate for x
replacement; that was Ed, who argued strongly for it. (Nobody else that I
recall claimed a need for it (but nobody argued against it, at least not
loudly).
>
> So I suppose Ed should weigh in on that question. I think that Ed wanted
only the single 'x' and only at the end of a year.
>
> > 1) Assuming that x's are only allowed to replace the last digit of a
> > year:
> >
> > I wonder whether there is a need for such a construction.
>
> Ed claims that there is.
>
> > 196x
> >
> > is easily (and more legibly) rewritten as
> >
> > {1960..1969}
>
> I don't know if that's easier or more legible.
>
> > {1958..1959, 196x, 1970}
> >
> > is probably better rewritten as
> >
> > {1958..1970}
> >
> > which is both shorter and more legible.
>
> Ok but it isn't hard to come up with a counterexample. In fact change the
above only slightly to:
>
> {1957..1958, 196x, 1971}
>
> Which without the xnotation would be:
>
> {1957..1958, 19601969, 1971}
>
> Which is more complex, though, I agree, only marginally so.
>
> > 2) Assuming that x's are allowed on other digits that the last digit of
> > a
> > year:
> >
> > I think that we should make clear that x's are allowed to replace any
> > digit, anywhere in a date.
>
> So 1x90 would mean: the years 1190, 1290, 1390, 1490, 1590, 1690,
1790,1890, 1990
> What would be a use case for this?
>
> > {1xx0, 2000}
> >
> > which would mean all years ending with a zero from 1000 inclusive to
> > 2000 inclusive and obviously is MUCH shorter than what it would be if
> > we do not allow x's on other digits than the last one in a year. I
> > wonder whether there are enough use cases for such constructions.
> >
> > In some cases, x's are maybe useful. Let's consider
> >
> > 201106xxT12:00:00
> >
> > which means at twelve o'clock every day during june 2011. According to
> > the BNF, such a construction is not unambigously allowed, though. I do
> > not how many use cases there are for such constructions.
> >
>
> Yes as you note, this is all about whether there are real use cases for
these notions. Lacking any, I would not want to pursue this beyond the
single 'x' at the end of a year.
>
> Ray

Edward C. Zimmermann, NONMONOTONIC LAB
http://www.nonmonotonic.net
UmsatzStID: DE130492967
