Chris Hostetter wrote:
: I would expect field:2001-03 to be a hit on a partial match such as
: field:[2001-02-28T00:00:00Z TO 2001-03-13T00:00:00Z]. I suppose that my
: expectation would be that field:2001-03 would be counted once per day for each
: day in its range. It would follow that a user
: I would expect field:2001-03 to be a hit on a partial match such as
: field:[2001-02-28T00:00:00Z TO 2001-03-13T00:00:00Z]. I suppose that my
: expectation would be that field:2001-03 would be counted once per day for each
: day in its range. It would follow that a user looking for documents re
On 6 Oct 09, at 5:31 PM, Chris Hostetter wrote:
...your expectations may be different then everyone elses. by
requiring
that the dates be explicit there is no ambiguity, you are in control
of
the behavior.
The power of some of the other formulas in ISO 8601 is that you don't
introduce f
Thanks for making me think about this a little bit deeper, Hoss.
Comments in-line.
Chris Hostetter wrote:
because those would be ambiguous. if you just indexed field:2001-03 would
you expect it to match field:[2001-02-28T00:00:00Z TO
2001-03-13T00:00:00Z] ... what about date faceting, what s
:My question is why isn't the DateField implementation of ISO 8601 broader
: so that it could include and MM as acceptable date strings? What
because those would be ambiguous. if you just indexed field:2001-03 would
you expect it to match field:[2001-02-28T00:00:00Z TO
20
> My question is why isn't the DateField implementation of ISO 8601 broader so
> that it could include and MM as acceptable date strings? What would
> it take to do so?
Nobody ever cared? But yes, you're right, the spurious precision is
annoying. However, there
e time part of the string is mandatory.
My question is why isn't the DateField implementation of ISO 8601
broader so that it could include and MM as acceptable date
strings? What would it take to do so? Are there any work-arounds for
faceting by century, year, month wit