Re: [hibernate-dev] HSEARCH Java 8 Date Time

Our current implementation converts Date in the long "distance from epoch" to allow correct range-queries treating each Date as an instant in time - allowing a universal sorting strategy. But a LocalDate is not an instant-in-time. A LocalDate is intentionally oblivious of the timezone; as the javadoc states, it's useful for birthdays, i.e. symbolic occurrences and potentially legal matters which don't fit into a universal sorting model but rather with the local political scene - we would need the combo {LocalDate, ZoneId} provided to be able to allow sorting across different LocalDate - or simply assume that they are all referring to the same Zone. I think that if the user is using a LocalDate type, he's implicitly hinting that the timezone is not relevant for the practical use (possibly even wrong); the most faithful representation would be the string form in ISO standard format or to encode the day,month,year as independent fields? This last detail depends on how it would be more efficient to store & query; probably the String format YYYYMMDD would be the most efficient internal representation to allow also correct sorting. I wouldn't use NumericField(s) in this case, as they are more effective only with larger ranges, while MM and DD are very short; not sure if it's worth splitting the year as a NumericField either, as the values will likely be strongly clustered in the same range of "recent years" - although that might depend on the application but it doesn't seem worth the complexity, so I'd index & store as a String YYYYMMDD. -- Sanne On 5 August 2015 at 11:10, Gunnar Morling <gunnar(a)hibernate.org&gt; wrote: