[hibernate-dev] 6.0 - HQL literals

[Steve Ebersole]

Sorry Yoann, it was a crazy week and I missed this reply somehow...

Yes, you did an awesome job with setting up tests.  We will obviously make
sure those continue to work as we move forward.

I did mention in the original email (I think anyway, I meant to) that there
seemed to be a problem in parsing with Java 8 in certain scenarios.  I
found this via a SO post asking why something was not working the way I
expected.  The answer was that there is a bug in Java 8, but that parseBest
seems to work consistently across both versions.  We plan to talk about
moving to Java 9 as a base anyway so this may not be an issue either way we
decide to go regarding parse or parseBest.


On Wed, Jan 8, 2020 at 4:21 AM Yoann Rodiere <yoann at hibernate.org> wrote:

> > This does nothing with Type.  The way the grammar is defined it
> literally 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.
>
> > As counter-intuitive as it sounds, a ZonedDateTime actually includes an
> 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/334e4aad5c776151bcf5dbb6d27bf61fc8a93443/util/common/src/main/java/org/hibernate/search/util/common/impl/TimeHelper.java#L38
>
> > I think the confusion here is in terms of (1) recognizing a temporal
> literal and "parsing it" and (2) applying it to SQL.  Different parts of
> the puzzle.
>
> Yep.
>
> Yoann Rodière
> Hibernate Team
> yoann at hibernate.org
>
>
> On Tue, 7 Jan 2020 at 19:50, Steve Ebersole <steve at hibernate.org> wrote:
>
>> As far as I know, even Java does not support that.  A true zone-id would
>>> be something like (for me) "America/Chicago".  If I ask Java to parse
>>> "2020-01-01 10:10:10 America/Chicago +02:00" it just says no.  For me, CST
>>> (standard) and CDT (daylight savings) are really synonyms for offset -
>>> either UTC-05:00 or UTC-06:00 depending on day of the year.
>>>
>>
>> It seems like the proper syntax for that would actually be "2020-01-01
>> 10:10:10+02:00 America/Chicago", but in my
>> testing DateTimeFormatter#parseBest did not handle that form either
>>
>>