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