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 <gun...@hibernate.org> wrote:
> Hi,
>
> What's the motivation for using a different representation in that case?
>
> For the sake of consistency, I'd use milli seconds since 1970-01-01 across
> the board. Otherwise it'll be more difficult to compare fields created from
> properties of different date types.
>
> --Gunnar
>
>
> 2015-08-04 19:49 GMT+02:00 Davide D'Alto <dav...@hibernate.org>:
>
>> Hi,
>> I started to work on the creation of the bridges for the classes in the
>> java.time package.
>>
>> I was wondering if we want to convert the values to long using the existing
>> approach we have now for java.util.Date.
>>
>> In Hibernate Search a java.util.Date is converted into a long that
>> represents the number of milliseconds since January 1, 1970, 00:00:00 GMT
>> using getTime().
>>
>> The same value can be obtain from a java.time.LocaDate via:
>>
>> long epochMilli = date.atStartOfDay( ZoneOffset.UTC
>> ).toInstant().toEpochMilli();
>>
>> LocalDate has a method that returns the same value expressed in number of
>> days:
>>
>> long epochDay = date.toEpochDay();
>>
>>
>> I would use the second approach
>>
>> Davide
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev@lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
_______________________________________________
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
