Re: [hibernate-dev] 6.0 - HQL literals

understands each piece of the temporal. So given, e.g., {2020-01-01}, we know that 2020 is the year, etc. This is the benefit of defining it syntactically. I trust you can build a temporal correctly from a string. I'm more concerned about passing that information to the JDBC driver through a parameter, or even directly to the database through an SQL literal. Last time I checked you had to use java.sql types to pass temporal parameters to JDBC drivers, so you will have to convert the java.time value to a java.sql.Timestamp or similar eventually. And *that* is much more tricky that I, at least, originally thought. Among other quirks: - creating a Timestamp from a year/day/etc. assumes the given year/day/etc. are in the default JVM timezone. - the JDBC driver will sometimes extract the year/day/etc. and interpret them as being in the DB timezone, or will sometimes use a DateFormat with a timezone to convert it to the correct timezone. It depends on the driver and even the version of the driver. - java.sql.Timestamp and java.time do not rely on the same calendar: Julian/Gregorian calendar for one, proleptic Gregorian calendar for the other. - java.sql.Timestamp and java.time do not assume the same offsets for various zone IDs around and before 1900, when time zones were not a formalized concept. I've spent days on conversion problems between java.time and java.sql in ORM over the last few months. Which is why I think using LocalDateTimeType to convert between the LocalDateTime literal and the Timestamp would be a good idea. If you want to rewrite that code for literals, sure that can work, but exhaustive testing will be needed. offset to differentiate the overlap case you mention. Yep. That's why it accepts parsing a ZoneDateTime with both a zone ID and an offset. Try this: https://gist.github.com/yrodiere/278996f865a9854e222aea58b5a7f26e Note that a bug affects parsing ZoneDateTimes with both offset and zone ID on JDK8 (fixed in 9): https://bugs.openjdk.java.net/browse/JDK-8066982 We have a helper to work around that in Search: https://github.com/hibernate/hibernate-search/blob/334e4aad5c776151bcf5db... literal and "parsing it" and (2) applying it to SQL. Different parts of the puzzle. Yep. Yoann Rodière Hibernate Team yoann(a)hibernate.org On Tue, 7 Jan 2020 at 19:50, Steve Ebersole <steve(a)hibernate.org&gt; wrote: