| It seems that dates from the JVM are interpreted as UTC dates and stored in Elasticsearch as such, independently of the JVM's default time zone. TL;DR This has the main advantage of allowing to write simple JSON queries easier, because it will be as if dates without timezones had a default timezone matching the JVM's default timezone. But on the other hand, this completely screws anyone wanting to do queries with explicit timezones, since the dates are stored with the wrong timezone. Full explanation To be more specific, if you have a Date object representing 2016-01-02T00:00, with the implicit (default) time zone being +01:00, HS will store this in Elasticsearch as 2016-01-02T00:00+00:00. Notice how the timezone got erased. (for information, it's done in org.hibernate.search.elasticsearch.util.impl.ElasticsearchDateHelper.dateToString(Date)) When querying through the DSL, everything will work fine, since HS will once again act as if the Date object provided to the match method was encoded for the UTC time zone. When building your own JSON query and asking HS to execute it as it is, things start to be a bit weird. This query string:
... will match. It should not, according to Elasticsearch's documentation, since dates without time zones are intepreted as UTC dates.
Well, whatever, we can say that's just a change of default timezone. But then you start working with multiple time zones, or with explicit time zones, and then you're screwed. The following query won't match, even though it uses the exact same date we previously had inside the JVM:
dateOfBirth:2016-01-02T00:00:00+01:00
Which is normal from ES's perspective, since we stored 2016-01-02T00:00:00+00:00, which is 2016-01-02T01:00:00+01:00 and does not match the query. But it's certainly not normal from a user's perspective. |