Hi, On Thu, Jan 5, 2017 at 5:20 PM, Yoann Rodiere <yo...@hibernate.org> 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. I would pay to see your face while reading this email :). -- Guillaume _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
