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
: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
2001-03
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
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
: 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
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 without creating new fields in my
schema
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 is no fuzzy search
