[hibernate-dev] HSEARCH Java 8 Date Time

[Davide D'Alto]

> wouldn't use NumericField(s) in this case, as they are more
> effective only with larger ranges, while MM and DD are very short;


I'm ok with that, it just that the @DateBridge annotation allows to choose
the encoding
and it would sound strange not to enable this annotation for this type.




On Wed, Aug 5, 2015 at 11:41 AM, Sanne Grinovero <sanne at hibernate.org>
wrote:

> 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 at 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 at 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 at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >>
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>