[
https://issues.apache.org/jira/browse/LUCENE-1070?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12546301
]
Mike Baroukh commented on LUCENE-1070:
--------------------------------------
I agree that nobody is forced to use DateTools.
I used my own version, of course.
But the report is not for *me*. It's just because I thought It was a bug.
I also know that for 2 same date, DateTools will return the same string.
My case is this :
I have Dates to index.
When Indexing, my Date objects contains hour and minutes.
when searching, date are typed by users without time. They are parsed with
dd/MM/yyyy pattern.
Because of the round() documentation, I thought there would be no problem
because I use "DAY" Resolution.
RTFM is not always a good option.
Finally, maybe it's not a bug, it's an architectural issue : when using long
for date, timezone is lost.
I continue to think that dateToString must take a Date for parameter. This way,
there would be no more ambiguity.
> 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]
