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 10:34:47 GMT
thanks for detailed explanation.

John Haxby wrote:
> 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
>
>

-- 
regards,
Volodymyr Bychkoviak


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