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

If a user select a resolution that does not make much sense we can log a warning.

But I think this might make sense: @DateBridge(resolution=MONTH) LocalDate birthday;

On Wed, Aug 5, 2015 at 3:37 PM, Davide D'Alto <davide(a)hibernate.org&gt; wrote: > > 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.

> > +1 > > > What do you suggest we do if a user maps the following? > > > @DateBridge(resolution=MILLISECOND) > > LocalDate birthday; > > > Nothing really, > I would just consider a LocalDate the same as a LocalDateTime with time > 00:00:000 (UTC time zone)

> > It is equivalent to: > LocalDateTime dateTime = date.atStartOfDay( ZoneOffset.UTC ); > > > > > > > > > > > On Wed, Aug 5, 2015 at 3:24 PM, Gunnar Morling <gunnar(a)hibernate.org&gt; > wrote: > >> >> >> 2015-08-05 12:41 GMT+02:00 Sanne Grinovero <sanne(a)hibernate.org&gt;: >> >>> 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&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