On Fri, 5 Oct 2018 at 14:40, Vlad Mihalcea <mihalcea.v...@gmail.com> wrote: > > Hi, > > My question was more about LocalTime, which is much more straightforward to > address than LocalDateTime in the context of time zones.
Ok so specifically discussing LocalTime. If you *really must* store a LocalTime as an absolute timestamp then using the "time_zone" configuration property sounds indeed like a better than not ignoring it. Yet my opinion - and what I believe many others here shared - is that LocalTime should not be map to such a SQL type; it should map to a different suitable type to represent "a description of the local time as seen on a wall clock" (quoting the LocalTime javadoc), e.g. on MySQL and PostgreSQL we map to TIME, not TIMESTAMP. > > For DateTime types which support timezones, I'll have to study to see what > other non-breaking alternatives we may have. > > Vlad > > On Fri, Oct 5, 2018 at 2:28 PM Steve Ebersole <st...@hibernate.org> wrote: >> >> Ah good, its time for this yearly discussion :D >> >> The problem is as Vlad points out. We are kind of forced to do *something* >> wrt timezone to often times counteract what the JDBC driver will do. As I >> have always contended, imo that saving a date into the database with any >> kind of timzone (other than UTC) is simply wrong. I personally would never >> do it - and I think we've seen enough of the down sides to doing it. As >> Sanne points out, storing epoch-based dates (Instant, etc) is always the >> best option >> >> One cool option would be an AttributeConverter that handles the timezone >> transformation, combined with telling Hibernate to always use UTC for the >> JDBC timezone >> >> >> On Fri, Oct 5, 2018 at 4:44 AM Sanne Grinovero <sa...@hibernate.org> wrote: >>> >>> On Fri, 5 Oct 2018 at 10:28, Vlad Mihalcea <mihalcea.v...@gmail.com> wrote: >>> > >>> > Hi >>> > >>> > IMO no timezone conversion whatsoever should be applied when >>> > > persisting LocalDateTime as it doesn't contain any TZ information. >>> > >>> > >>> > That's not very easy to do since either the JDBC Driver or the database >>> > engine might to the timezone conversion based on the underlying setting. >>> > >>> > In fact I'd even recommend to use a string-based column type to store >>> > > LDT, as it avoids these kinds of issues altogether. >>> >>> +1 I think we need to enforce that. Mapping a Java type which is >>> explicitly designed to be insensitive to TZ should not be stored into >>> a type which is sensitive to it. That would otherwise defeat the >>> purpose of using these specific types. >>> >>> If people really want to convert stuff, that's business logic. So that >>> belong in the business layer: let them do explicit conversion in their >>> own code before invoking the setter of an entity, that will also help >>> to bring awareness on any conversion issue they might have. >>> >>> > >>> > >>> > Actually, a Long (BigInt) column type with the epoch would be more >>> > suitable >>> > than a CHAR-based column since it's more compact and achieves the same >>> > goal. >>> > However, many clients will not want to store Date/Time in Int or String >>> > columns as explained in the following article: >>> >>> -1 >>> >>> let's use Epoch based numerics for Java types which are based on >>> Epoch. e.g. java.time.Instant. >>> >>> People can always transform a date into an epoch-independent number by >>> simply encoding it as a number; >>> e.g. "2018-10-31" -> 20181031 . I guess it could save you some bytes >>> but I'd be skeptical on doing this automatically. >>> >>> > >>> > https://www.periscopedata.com/blog/better-sql-schema >>> > >>> > 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? >>> > >>> > >>> > We would have to introduce a new configuration property as a strategy >>> > where >>> > the current behavior is "legacy" >>> > while the new one must be explicitly enabled. >>> > >>> > Vlad >>> > >>> > On Fri, Oct 5, 2018 at 11:17 AM Yoann Rodiere <yo...@hibernate.org> wrote: >>> > >>> > > > 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 >>> >>> _______________________________________________ >>> 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
