[
https://issues.apache.org/jira/browse/LUCENE-1070?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12546284
]
Alexei Dets commented on LUCENE-1070:
-------------------------------------
I'm not a Lucene developer but just wanted to comment from a user perspective -
I found the current Lucene behavior 100% correct and this bug report wrong.
First of all, AFAIK this doesn't have anything to do with the DAY precision -
with any higher precision one can also get other day (and other hour), this is
just how timezones work: conversion from one timezone to another changes time.
But then during the search one should also use DateTools.dateToString and the
search will work correctly. And after applying DateTools.stringToDate on search
results you'll get the correct dates.
Search with a DAY precision will search for the given day in UTC timezone not
in a local one, if it is not sufficient for your purposes then you should use
an HOUR precision during indexing and search - DAY is simply not precise enough
for your purposes. Another alternative that should probably work (I never
tried) is to create your Date (that you are passing to DateTools.dateToString)
in UTC timezone, in this case no timezone conversion should be applied unless
there is some bug in DateTools and you'll get exactly the same day indexed (but
then on retrieving results DateTools.stringToDate will change you day because
it'll apply the local timezone). And after all nobody is forced to use
DateTools and can implement their own way to store dates if no timezone
conversions are required - it is probably the best way for this _specific_ case.
> DateTools with DAY resoltion dosn't work depending on your timezone
> -------------------------------------------------------------------
>
> Key: LUCENE-1070
> URL: https://issues.apache.org/jira/browse/LUCENE-1070
> Project: Lucene - Java
> Issue Type: Bug
> Affects Versions: 2.2
> Reporter: Mike Baroukh
>
> Hi.
> There is another issue, closed, that introduced a bug :
> https://issues.apache.org/jira/browse/LUCENE-491
> Here is a simple TestCase :
> DateFormat df = new SimpleDateFormat("dd/MM/yyyy HH:mm");
> Date d1 = df.parse("10/10/2008 10:00");
> System.err.println(DateTools.dateToString(d1, Resolution.DAY));
> Date d2 = df.parse("10/10/2008 00:00");
> System.err.println(DateTools.dateToString(d2, Resolution.DAY));
> this output :
> 20081010
> 20081009
> So, days are the same, but with DAY resolution, the value indexed doesn't
> refer to the same day.
> This is because of DateTools.round() : using a Calendar initialised to GMT
> can make that the Date given is on yesterday depending on my timezone .
> The part I don't understand is why take a date for inputfield then convert
> it to calendar then convert it again before printing ?
> This operation is supposed to "round" the date but using simply DateFormat to
> format the date and print only wanted fields do the same work, isn't it ?
> The problem is : I see absolutly no solution actually. We could have a
> WorkAround if datetoString() took a Date as inputField but with a long, the
> timezone is lost.
> I also suppose that the correction made on the other issue
> (https://issues.apache.org/jira/browse/LUCENE-491) is worse than the bug
> because it correct only for those who use date with a different timezone than
> the local timezone of the JVM.
> So, my solution : add a DateTools.dateToString() that take a Date in
> parameter and deprecate the version that use a long.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
