> In fact I'd even recommend to use a string-based column type to store
> LDT, as it avoids these kinds of issues altogether.
Or just, you know, "timestamp without timezone". Where possible.
More to the point, I agree with Vlad's proposition, and I also think ORM
should avoid messing with timezones as much as possible: when the user
didn't provide one (LocalDate, LocalDateTime, Date), don't store one, when
he provided one (ZonedDateTime, OffsetDateTime, Calendar, ...), store it
exactly as provided. The goal being to return the exact value that was
persisted when later retrieving the data.
But unfortunately I think there is a lot of legacy behaviors that differ
from this, so any attempt at "fixing" it would break compatibility and make
someone angry.
Maybe introducing another value for "hibernate.jdbc.time_zone" ("as_is"?)
that would also impact how we map timezone-less types, would be a good idea?
Yoann Rodière
Hibernate NoORM Team
yo...@hibernate.org
On Fri, 5 Oct 2018 at 09:38, Gunnar Morling <gun...@hibernate.org> wrote:
> 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
>
_______________________________________________
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
