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

> 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(a)hibernate.org&gt; 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(a)hibernate.org&gt; 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&gt;: > > > >> 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 > _______________________________________________ hibernate-dev mailing list hibernate-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev