lucene-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From John Haxby <...@scalix.com>
Subject Re: DateTools again
Date Tue, 03 Oct 2006 10:22:44 GMT
Volodymyr Bychkoviak wrote:
> User has an input (javaScript calendar) on page where he can choose 
> some date to include in search. Search resolution is day resolution.
>
> If user will enter same date in different time of date he will get 
> different results (because calendar will also set current hour and 
> minute in the date). But this is not right behavior.
>
> I propose not to use GMT when rounding time to selected resolution. 
> This will prevent us from situation described above.
>
> This can be done by replacing two lines  "Calendar cal = 
> Calendar.getInstance(GMT);" with "Calendar cal = Calendar.getInstance();"

I don't think you're improving matters there: you might be 
cancelling-out the effects of timezone adjustment when everyone is in 
the same timezone, but if you have users on a browser in one timezone 
and the server is in a different timezone then you're in for 
interestingly broken results.

There's also the interesting decision about when a day starts.   You're 
using "Etc/GMT-2" instead of (for example) "Europe/Moscow" -- do you 
have daylight savings time?   What happens on the day the clocks 
change?   Is the answer different for spring and summer?   If a document 
is dated, let's say, 00:30 (half an hour after midnight) is its day 
number dependent on the time zone?   What's half an hour after midnight 
when the clocks change?

You say you're using javascript to get a date in a browser -- would it 
not be better to remove the time of day there and just leave you with 
the date?   And have the date as a string so you're not dealing with 
boundary conditions?

When I was struggling with this for mail messages I eventually decided 
that it really only makes sense to deal with GMT.   If some client wants 
messages delivered on, let say, 14-Jul-2006 then the client has to 
produce the range of times that make most sense for it to be 
14-Jul-2006.   Here in the UK that's 13-Jul-2006 23:00:00 UTC to 
14-Jul-2006 22:59:59.   In San Francisco it would be 5pm to 5pm UTC, in 
Moscow, well, you work it out.    Of course, users in San Francisco, 
Wokingham (where I am) and Moscow wouldn't see the same set of documents 
dated 14-Jul-2006, but they'd none of them would see documents dated the 
day before or the day after in their local timezone.   If you want 
everyone to see the same set of documents for Bastille Day then use UTC 
throughout.

I'm not sure what you're doing in javascript, but it may be enough to 
pass along the timezone correction along with the time and use that to 
get the search that you want.

jch

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


Mime
View raw message