IMO no timezone conversion whatsoever should be applied when persisting LocalDateTime as it doesn't contain any TZ information.
If the target column type requires a TZ, it should be set to UTC, storing the given value without any shift. I.e. the LDT value 2007-12-03T10:15:30 should be stored as 2007-12-03T10:15:30@UTC, no matter what's the VM's timezone or any TZ related config. This allows to retrieve the original value later on, also if e.g. the loading VM is in a different TZ. In fact I'd even recommend to use a string-based column type to store LDT, as it avoids these kinds of issues altogether. --Gunnar Am Fr., 5. Okt. 2018 um 07:15 Uhr schrieb Vlad Mihalcea <mihalcea.v...@gmail.com>: > > Hi, > While reviewing this Jira issue: > > https://hibernate.atlassian.net/browse/HHH-12988 > > and further discussing it via Twitter, I wonder if we should persist > LocalTime as-is without any TimeZone transformation > that may be done if we enable `hibernate.jdbc.time_zone`? > > According to the Date/Time API, LocalTime should not be relative to any > TimeZone. > > If we make this change, it means we need to use a LocalTime SQL descriptor > that ignores the jdbc.time_zone property, > and the change is going to break compatibility as well. > > Vlad > _______________________________________________ > hibernate-dev mailing list > hibernate-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
