hi there,

i got a problem with a special date here, an object contains a java.util.date like this:



in my database there is one special entry, which has datum="2009-12-22 00:00:00.0".

If i'm building a range query like:


i also get this named special entry in my result list, which shouldnt be there, or should it?
increasing the hour of the document didnt solve the problem. is there something special with this date?
rebuilding the index always maps "2009-12-22 00:00:00.0" to "20091221", which isnt the behaviour i expected here.

btw: still using hs 3.0.1

you might have a problem with timezone settings, unfortunately converting a java.util.Date to a String-date representation depends on the timezone configured for the JVM - default to the server settings.

Imagine your server timezone is having a -1 hour compared to your database, in this case the datum "2009-12-22 00:00:00.0" would be interpreted as "2009-12-21 23:00:00.0", just as an example, which would be truncated to 2009-12-21.

that was something i already thought about, so i increased the time to 1 am (2009-12-22 13:00:00.0) in the database and rebuild the index, but that didnt solve the problem.

(system.getproperty("user.timezone")) is tellin me, that my server is set to the right timezone)

you could have more than a single hour of difference?


is it matching the database timezone?

sorry, my fault. meant 1pm, not 1am, not used to work with these kind of time namings :)

but i meanwhile recognized another issue, the class contais some other dates, which all mapped as timestamps in the hibernate mapping, just the one i mentioned above is mapped as a date, like this:



timezone of the db also already checked and as classified as the correct one.

now i discovered something really strange, i change the resolution of "datum" to Resolution.HOUR (from Resolution.DAY), rebuild the index, set up my query, and i wont get it as a result of the range query.
But, when i inspect my index with Luke, the entry for "datum" there is still 20091221, i dont get it, why it now wont appear in my result list. Strange one.

anybody? its a workaround ok, but it doesnt really solve the problem itsself

would you be able to provide a failing unit test?

it's hard to tell what's wrong

The @DateBridge annotation expects dates to be in the GMT format. So if the date in your database is stored in anything but GMT, things will break: your date is converted to a String as if it were GMT. Spefically, the DateTools functions that DateBridge uses internally cause this. So the x hours difference between your timezone and GMT may cause the string representation of the date to have another day than the actual date in your database!

Actually, I also encountered this problem earlier, and storing all our dates in GMT wasn't an option. Thus I ended up writing a custom bridge for date fields, which converts dates to string taking the timezone into account.
I think it would be a nice feature if the HS DateBridge could take timezones into account, since currently it breaks quietly if you don't provide a GMT date, which can be quite confusing.

of course storing dates in GMT format is the only viable solution to make the index format consistent across regions and server reconfigurations.
I'd recommend to convert your range queries to use GMT formatted dates too, and verify that the Date conversion from database to java is fine.


feel free to open a feature request; if you could add a patch even better!

Agreed, GMT is pretty much required if you have to share the index across regions. For a local application (or a 'master' server location) it can be convenient to work with the local time zone though. I don't think a local server would suddenly shift timezones (unless your country switches like the UK is considering... ;)

Always converting the database dates for querying seems like a hassle, but it's a good approach too. Hmm, I'll have to think about this a bit.

right but we could help on that by managing that in the new Query API, not sure if there's something related to Date already. There are experiments in current trunk, you might look there and early feedback and patches are really welcome.

Using GMT on the index is just safer, application correctness won't depend on server configuration mistakes, and you can also dump/restore the server across regions, you might find many use cases even if your app serves only a single region. (And then what if you have two different regions to serve?)
It definitely needs to contextualize the meaning of day at query time.