lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alexei Dets (JIRA)" <>
Subject [jira] Commented: (LUCENE-1070) DateTools with DAY resoltion dosn't work depending on your timezone
Date Wed, 28 Nov 2007 16:01:45 GMT


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:
>             Project: Lucene - Java
>          Issue Type: Bug
>    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