For example, 2018-03-25T02:00:00.0 is not valid in the timezone Europe/Paris, because the DST starts at that time, so 2AM never occurred that day and people leaped from 1:59AM to 3AM directly.

A LocalDate representing 2018-03-25T02:00:00.0 can still exist (and be legitimate) in an application. But as soon as one tries to persist this value through Hibernate ORM, the LocalDate will be converted to a Timestamp using the default JVM timezone, and if this timezone happens to be Europe/Paris, the LocalDate will be silently chaned to 2018-03-25T03:00:00.0. Whether the shift happens on database write or read is not clear yet.

This looks odd: a LocalDate is supposedly not related to the JVM timezone and should not be affected by it.

Note the problem happens even when the JDBC timezone is set to GMT.

I do not think it's a recent regression, but rather a bug that's always been there.

See the commented data set added to LocalDateTimeTest as part of HHH-13379 Open .