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.
h2. TL;DR
This The current behavior has the main advantage of allowing to write simple JSON queries easier more easily , because it dates without timezones will be interpreted as if dates without timezones they had a default timezone matching the JVM's default timezone.
But on the other hand, this behavior completely screws anyone wanting to do queries with explicit timezones, since the dates are stored with the wrong timezone.
h2. 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:
{code}
dateOfBirth:2016-01-02
{code}
... will match. It should not, according to [Elasticsearch's documentation|https://www.elastic.co/guide/en/elasticsearch/reference/current/query-dsl-range-query.html#_time_zone_in_range_queries], 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:
{code}
dateOfBirth:2016-01-02T00:00:00+01:00
{code}
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. |
|