lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Uwe Schindler (JIRA)" <>
Subject [jira] Closed: (LUCENE-1070) DateTools with DAY resoltion dosn't work depending on your timezone
Date Thu, 27 Jan 2011 10:47:46 GMT


Uwe Schindler closed LUCENE-1070.

    Resolution: Not A Problem

stringToDate and dateToString are symmetric so this is not an issue. The first comment already
explains why UTC is correct.

Closing this because of long inactivity.

> DateTools with DAY resoltion dosn't work depending on your timezone
> -------------------------------------------------------------------
>                 Key: LUCENE-1070
>                 URL:
>             Project: Lucene - Java
>          Issue Type: Bug
>          Components: Index
>    Affects Versions: 2.2
>            Reporter: Mike Baroukh
> Hi.
> There is another issue, closed, that introduced a bug :
> 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 (
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:
For additional commands, e-mail:

View raw message