Re: [hibernate-dev] [SEARCH] Remove support for (or deprecate) date/calendar resolution?

even when we didn't use HS but Solr, we needed an equivalent feature). Using range queries is a solution but it's a bit cumbersome for such a common requirement. Please note that Hibernate Search queries are now built using a wrapper in OWSI-Core <https://github.com/openwide-java/owsi-core-parent/blob/bd6ab1ec1d54c22ed3... in most recent applications, and it could easily be adapted to add a Date match method (using method overloading). In fact, if I remember correctly I had to do exactly that for one application. One thing to note about the OW use case, too: I've never seen anything other than a Date being used in business models of single-timezone applications at Open Wide. See below why it's relevant. An easier implementation would be what you did with Elasticsearch using the clone() method. But anyway, this would only fix the issue for Calendar. For Date, we basically only have a GMT timestamp with no timezone data nor field-based data, so there's really nothing we can do. If we want to fix the default behavior for dates, the only solution I can see is to use the default JVM timezone instead of GMT, maybe... a different date in a different time zone, then you definitely wouldn't use the resolution option and stick to the full date with range queries. All dates in one time zone may be a different date in a different time zone... In fact, I'm pretty sure all dates in one time zone *are* a different date in one different time zone. I see what you mean, but I just wanted to point out how difficult it will be to explain properly in the documentation. I don't know about you, but I really don't want to explain in the docs that "this feature should only be used with java.util.Date if your timezone is close to GMT", and I want even less to explain why... Anyway, you do understand we're offering a feature that won't work properly in most time zones, and will simply not work most of the time in time zones such as, for instance, the one for the US west coast (UTC-8)? (in that specific case it won't work after 4 PM). Could we agree the current behavior should change, not only for java.util.Calendar but also for java.util.Date? If we do, we'll probably have to wait for 6.0, because users will have to perform a full reindex after upgrading to a version of Hibernate Search with the fix, even if they previously weren't affected by the bug. Also: implement automatic truncation with date/time types where the timezone is either irrelevant or included (for instance ZonedDateTime or LocalDate or LocalTime, but *not* Instant). Do you agree with the statement above? Yeah, well, not much surprise here :) Yoann Rodière <yoann(a)hibernate.org&gt; Hibernate NoORM Team On 9 January 2017 at 12:53, Guillaume Smet <guillaume.smet(a)gmail.com&gt; wrote: > Hi, > > On Thu, Jan 5, 2017 at 5:20 PM, Yoann Rodiere <yoann(a)hibernate.org&gt; wrote: > >> That's a catchy subject, now I'm sure I got Guillaume's (angry) attention >> :) >> >> Sanne wanted us to think about feature removal... Here's a proposal. >> >> The feature I'd like to deprecate/remove: automatic truncation of >> date/calendars to a given resolution. It's used like that: >> > > Yeah, as you can imagine, I'm pretty reluctant to the idea of removing > this feature. We used it a lot at OW and I'm sure it's pretty widespread > out there (and even when we didn't use HS but Solr, we needed an equivalent > feature). Using range queries is a solution but it's a bit cumbersome for > such a common requirement. > > I agree the current behavior might lead to unexpected results. To be > honest, I think we should simply ignore the timezone when truncating. I > mean, when I want to index at a day resolution, I want to index the user > facing day, not the one in the server time zone or in GMT. > > So for instance, for 2016-01-01T00:00:00+01:00, I would index 2016-01-01, > not 2015-12-31. > > So, as long as the resolution is less precise than day included, what I > would do is in fact remove our call to DateTools.round and have something > like: > - create a GMT GregorianCalendar > - don't set the calendar value using the time in millis but with the > original fields from the calendar passed in parameter (or 0/1 depending on > the resolution) > - index this value > > I think this new behavior would fix most of the issues you mention. And if > you really need the behavior when dates in one time zone might be a > different date in a different time zone, then you definitely wouldn't use > the resolution option and stick to the full date with range queries. > > So I agree the current behavior is probably not what user expects but I > think it has value. > > > -- > Guillaume >