I have been happily using Search (3.3.0 FINAL) in a mission critical financial trading application until I noticed that date handling is broken. We use Hibernate with Oracle (ojdbc14-10.2.0.4 driver) as our persistence layer.

Some dates are loaded by Hibernate as java.sql.Timestamp instances. When these timestamp instances are processed by the out-of-the-box DateBridge bad things happen.

Anyone else experiencing this problem? The fix is to build a replacement for the out-of-the-box date bridge implementation that does not make use of the Lucene DateTools class. I have an implementation that solves this issue, gets rid of heavy synchronization that may limit performance of optimized (i.e. multi-threaded - mass indexing), and fixes another major bug (if you use Resolution.DAY then DateTools will drop the day instead of dropping the hour).

Another problem is that DateTools assumes that the dates being fed to it are in GMT. This is a huge (bad) assumption. The solution is to let user specify the desired TimeZone - using annotations of course.

I will post this to the Lucene team as well.

Hi,

thanks for your feedback.

Can you elaborate on this? What is the problem with java.sql.Timestamp?Maybe you could create an issue in http://opensource.atlassian.com/project ... se/HSEARCH including a testcase?


I guess you are talking about https://issues.apache.org/jira/browse/LUCENE-1070. Your problem seems to be caused by using a non UTC time zone. If you want to stick with that, the right approach is to use a custom bridge implementation. Personally I think it makes sense to store all dates in the UTC timezone and to make sure that dates entered by users or used for searches get the same treatment. What if the timezone of your server changes?

--Hardy

We use Hibernate/Search in a mission critical fixed income trading application. Complete indexing is done, in a fixed timezone, at the end of each day - thus conversion of dates to-from GMT is not necessary. As you point out, the solution was a custom date bridge that allows timezone to be specified via annotations. In our patch the annotation looks like the following ('default' is the default timezone):




The problem with java.sql.Timestamp is that it contains nanosecond resolution and for some cases - e.g. time is set to 00:00:00 - it can cause the date to be incorrectly converted to a String.

From the javadocs of java.sql.Timestamp:



So you definitely need a custom bridge for Timestamp.