lucene-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Volodymyr Bychkoviak <vbychkov...@i-hypergrid.com>
Subject Re: DateTools again
Date Tue, 03 Oct 2006 08:55:59 GMT
Ok, I'll try to explain a bit.

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();"

John Haxby wrote:
> Volodymyr Bychkoviak wrote:
>> I'm using DateTools with Resolution.DAY.
>> I know that dates internally are converted to GMT.
>>
>> Converting dates "2006-10-01 00:00" and "2006-10-01 15:00" from 
>> "Etc/GMT-2" timezone will give us
>> "20060930" and "20061001" respectively.
>>
>> But these dates are identical with day resolution.
>>
>> Is this bug or I'm missing something?
>>
> They're not identical.   The first one is 2006-09-30 22:00:00 UTC and 
> the second 2006-10-01 13:00:00 UTC.
>
> I ran across the problem with DateTools not using UTC when I tried to 
> use an index created in California from the UK: I was looking for 
> documents with a particular date stamp but I found documents with a 
> date stamp from the wrong day.  Even more interesting and bizarre 
> things happen around the change from daylight savings time to normal 
> time.
>
> jch
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-user-help@lucene.apache.org
>
>

-- 
regards,
Volodymyr Bychkoviak


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message