Re: [hibernate-dev] HSEARCH Java 8 Date Time
2015-08-05 12:41 GMT+02:00 Sanne Grinovero <sanne(a)hibernate.org>:
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.
Right, I had the latter in mind and would use UTC for that purpose.
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.
Agreed that this makes most sense, given the "symbolic" nature of LocalDate.
What would you do though in case of the following:
@DateBridge
LocalDate myDate;
encoding() defaults to NUMERIC, so would you a) raise an error, or b)
ignore encoding() for LocalDate and friends? Both seem not right to me. I
think there is nothing wrong with using NUMERIC encoding per-se for these
types. We may recommend STRING but if NUMERIC really is what a user wants I
would let them do so.
-- Sanne
On 5 August 2015 at 11:10, Gunnar Morling <gunnar(a)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 <davide(a)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(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev