You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by "Mike Baroukh (JIRA)" <ji...@apache.org> on 2007/11/27 19:15:43 UTC
[jira] Created: (LUCENE-1070) DateTools with DAY resoltion dosn't
work depending on your timezone
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: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
[jira] Commented: (LUCENE-1070) DateTools with DAY resoltion dosn't
work depending on your timezone
Posted by "Alexei Dets (JIRA)" <ji...@apache.org>.
[ 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: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
[jira] Commented: (LUCENE-1070) DateTools with DAY resoltion dosn't
work depending on your timezone
Posted by "Mike Baroukh (JIRA)" <ji...@apache.org>.
[ 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: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
[jira] Commented: (LUCENE-1070) DateTools with DAY resoltion dosn't
work depending on your timezone
Posted by "Kevin Conaway (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LUCENE-1070?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12570412#action_12570412 ]
Kevin Conaway commented on LUCENE-1070:
---------------------------------------
If the behavior is correct, it is extremely unintuitive.
One would expect that dateToString() and stringToDate() would be symmetric.
> 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: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org