Regression of Instant serialization

Description

When an entity with an Instant field is persisted and then retrieved, the instants before saving and after retrieving are different when the original Instant was a DST end.

It was probably introduced by this commit which is associated to this ticket.

Here's a demo repository.
When executed, it will produce the following logs which shows the difference between the instants:

It happens since version 5.4.2.
Uncomment line 19 in the pom.xml of the demo in order to test with version 5.4.1 which will produce the following logs:

Environment

None

Activity

Show:
Yoann Rodière
July 26, 2019, 1:38 PM

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:

  1. 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.

  2. 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:

  1. 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.

  2. 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.

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.

Gail Badner
July 29, 2019, 7:59 PM

Fixed in master.

Gail Badner
August 2, 2019, 10:45 PM

Fixed in 5.3 branch as well.

Assignee

Yoann Rodière

Reporter

Romain Moreau

Fix versions

Labels

None

backPortable

Backport?

Suitable for new contributors

None

Requires Release Note

None

backportDecision

None

Worked in

5.4.1

Components

Affects versions

Priority

Major
Configure