problems with date ranges in queryParser

[Daniel Naber <lu...@danielnaber.de>]

Hi,

QueryParser can parse input like [01.01.2005 TO 15.01.2005] if the German 
locale is activated ("01.01.2005" is the way 2005-01-01 is usually written 
in Germany). By "can parse" I mean that the date is recognized and 
automatically turned into the format used by DateField (like "0e9eodds0"). 
There are two problems with that:

1.) We now have DateField and DateTools which use different formats. So 
QueryParser needs to know which one has been used during indexing. I've a 
local patch that adds an appropriate set... method.

2.) Range queries with [...] are supposed to be inclusive, but that doesn't 
work as the use will expect with dates if the resolution of the query is 
less than the indexing resolution. So if someone queries for [01.01.2005 
TO 15.01.2005] he expects to get documents from 15.01.2005, too. The index 
might contain fields like 2005011520015 (i.e. 2005-01-15 20:15) for this, 
but the query is turned into [20050101 TO 20050115], so that document is 
not found.

Does anybody have any idea how to solve problem 2.? You cannot just set the 
time to 23:59:59 because with the current implementation you cannot tell 
whether the time was specified by the user.

Regards
 Daniel

-- 
http://www.danielnaber.de

---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org

Re: problems with date ranges in queryParser

[Chris Hostetter <ho...@fucit.org>]

: 1.) We now have DateField and DateTools which use different formats. So
: QueryParser needs to know which one has been used during indexing. I've a
: local patch that adds an appropriate set... method.

A much as i dislike the "standard" mechanism for indexing Dates, I'm of
the opinion that if people want to format their dates differently at index
time (either using DateTOols, or anything else), it's perfectly reasonable
to require that they subclass QueryParser and override getRangeQuery so
that it knows exactly how to convert the date to their index format.

: 2.) Range queries with [...] are supposed to be inclusive, but that doesn't
: work as the use will expect with dates if the resolution of the query is
: less than the indexing resolution. So if someone queries for [01.01.2005
: TO 15.01.2005] he expects to get documents from 15.01.2005, too. The index
: might contain fields like 2005011520015 (i.e. 2005-01-15 20:15) for this,
: but the query is turned into [20050101 TO 20050115], so that document is
: not found.
:
: Does anybody have any idea how to solve problem 2.? You cannot just set the
: time to 23:59:59 because with the current implementation you cannot tell
: whether the time was specified by the user.

If I understand your concern, it's that in QP.getRangeQuery, after calling
df.parse(part2) you don't know if the user specified a time or not.  if
they did you don't want to muck with it, and if they didn't you want to
set the time to 23:59:59.999 so you are as inclusive as possible of the
"date" they specified.

Am I understading you correctly?

a) QP.getRangeQuery calls DateFormat.getDateInstance -- not
DateFormat.getDateTimeInstance ... so unless I'm missing something, the
issue seems moot: people aren't allowed to specify a time, so you should
allways be able to add 1 day to the end date and make the range exclusive
of the end term.

b) let's assume you want to change that so it does call
getDateTimeInstance...

It's been a while since i messed with Date parsing/formating in depth, but
I remember correctly DateFormat exposes the Calendar object it's using,
and prior to calling df.parse() you can set the
hour/minute/second/millisecond values on the underlying Calendar.  then
when the dateformater does it's parsing, it only modifies the values it
sees in the string it's parsing, and leaves the existing values alone (so
if the user specifies a time, it uses it; if they don't it uses the one
you specified in advance (23:59:59.9999999)


...i could be wrong about being able to use the Calendar that way ... a
quick unit test will tell you if i'm right.



-Hoss


---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org