| I just had a look. This is indeed caused by the fix for HSEARCH-13266, introduced in 5.4.2 and 5.3.10. It's a bit more complicated than just "it broke everything", though. There are two cases to keep in mind:
- When no JDBC timezone is set, Hibernate ORM simply cannot handle date/times at DST end correctly.
These dates have an ambiguous "local" representation (year/month/.../seconds/nanoseconds, without offset or zone),
and JDBC drivers generally rely on java.time to convert the timestamp to that representation,
so they hit JDK-4312621 and end up storing the wrong date/time.
- When the JDBC timezone is set, and is a timezone that does not use DST (such as GMT or UTC),
Hibernate ORM can handle dates at DST end correctly,
because there is no ambiguity in the timestamps sent to and retrieved from the JDBC drivers
(which use GMT/UTC).
The fix for HSEARCH-13266 led to a regression in both cases, but... in different ways:
- When no JDBC timezone is set, Hibernate ORM used to interpret ambiguous values read from the database as after the DST end.
After HSEARCH-13266, it started interpreting them as before the DST end.
It's a compatibility break, but both approaches are technically just as correct.
- When the JDBC timezone is set, and is a timezone that does not use DST (such as GMT or UTC),
Hibernate ORM used to handle ambiguous values correctly.
After HSEARCH-13266, it started systematically writing the value before the DST end to the database,
even when the instant represented by the java object (Instant, ZonedDateTime, ...) was the one after the DST end.
This is obviously a bug.
Gail Badner I prepared a PR to test the regression and fix the problem.
I essentially rolled back to the old behavior, but only for dates after 1905.
These are the only dates that can involve DST, and they are not affected by HSEARCH-13266 anyway,
so we should get the best of both worlds.
The PR fixes both case 1 and case 2. |
