You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-user@lucene.apache.org by Volodymyr Bychkoviak <vb...@i-hypergrid.com> on 2006/10/02 16:53:37 UTC
DateTools again
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?
--
regards,
Volodymyr Bychkoviak
Re: DateTools again
Posted by Volodymyr Bychkoviak <vb...@i-hypergrid.com>.
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
Re: DateTools again
Posted by John Haxby <jc...@scalix.com>.
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
Re: DateTools again
Posted by John Haxby <jc...@scalix.com>.
John Haxby wrote:
> 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.
That's confusing isn't it? Originally DateTools didn't use UTC for its
conversions: I submitted a patch some time ago (well before 2.0) that
made it use UTC. Does that make it less confusing?
jch
---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-user-help@lucene.apache.org
Re: DateTools again
Posted by Volodymyr Bychkoviak <vb...@i-hypergrid.com>.
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
Re: DateTools again
Posted by John Haxby <jc...@scalix.com>.
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