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: [UTF-8?]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 counter-example. In fact change the 
above only slightly to:
> 
> {1957..1958, 196x, 1971}
> 
> Which without the x-notation would be:
> 
> {1957..1958, 1960-1969, 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
> > 
> > 2011-06-xxT12: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
Umsatz-St-ID: DE130492967