Fixed
Details
Assignee
UnassignedUnassignedReporter
Philippe MarschallPhilippe MarschallComponents
Fix versions
Priority
Minor
Details
Details
Assignee
Unassigned
UnassignedReporter
Philippe Marschall
Philippe MarschallComponents
Fix versions
Priority
Created May 25, 2017 at 8:05 PM
Updated December 3, 2024 at 9:49 AM
Resolved March 23, 2024 at 6:17 PM
JDBC 4.2 introduces the types
TIMESTAMP_WITH_TIMEZONE
andTIME_WITH_TIMEZONE
but no corresponding type names are registered.This causes DDL generation to fail.
In this Pull Request, we got some hints about some possible issues related to
LocalDateTime
andLocalTime
:Speaking of which right now Hibernate implements support for LocalDateTime and LocalTime by converting through java.sql types. This is not optimal for two reasons LocalTime has nanosecond resolution java.sql.Time has millisecond resolution, converting results in silent data truncation. java.sql.Timestamp due to implementation details is affected by daylight savings time even though it shouldn't be. If you run your JVM in a time zone that has daylight savings time the following value can not be stored or loaded correctly when a conversion through java.sql.Timestamp happens. It can only be stored and loaded correctly when driver support for JSR-310 is used. private static LocalDateTime getUnstorableValue() { ZoneId systemTimezone = ZoneId.systemDefault(); Instant now = Instant.now(); ZoneRules rules = systemTimezone.getRules(); ZoneOffsetTransition transition = rules.nextTransition(now); assertNotNull(transition); if (!transition.getDateTimeBefore().isBefore(transition.getDateTimeAfter())) { transition = rules.nextTransition(transition.getInstant().plusSeconds(1L)); assertNotNull(transition); } Duration gap = Duration.between(transition.getDateTimeBefore(), transition.getDateTimeAfter()); return transition.getDateTimeBefore().plus(gap.dividedBy(2L)); }