[hibernate-dev] Should the LocalTimeType use the globally configured TimeZone?

Fri Oct 5 08:29:59 EDT 2018

On Fri, 5 Oct 2018 at 12:47, Steve Ebersole <steve at hibernate.org> wrote:
>
> Ah good, its time for this yearly discussion :D

Lol :)

but don't we have better options now with the new Date/Time API?

The old "Date" certainly was ambiguous in this regard, as one had a
single business type which could be occasionally used as a universal
timestamp, occasionally as a local political/human meaning; with Date
it was up to us to try hard to do the "right thing", and it was hard.

With the new types I would expect that we can guide people by not
allowing mixed mappings; so the epoch based Instant gets mapped to
whatever the specific database has to map epoch based timestamps,
while the political types would not.

I would simply expect that we would disallow conversions between the
two - at least unless there's a very explicit request to break sanity
rules - but I'd rather have it sane by default so to encourage people
to use the right Java types for their specific needs.

Thanks,
Sanne

>
> 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 <sanne at hibernate.org> wrote:
>>
>> On Fri, 5 Oct 2018 at 10:28, Vlad Mihalcea <mihalcea.vlad at 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 <yoann at 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
>> > > yoann at hibernate.org
>> > >
>> > >
>> > > On Fri, 5 Oct 2018 at 09:38, Gunnar Morling <gunnar at 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 at 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.vlad at 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 at lists.jboss.org
>> > >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> > >> _______________________________________________
>> > >> hibernate-dev mailing list
>> > >> hibernate-dev at lists.jboss.org
>> > >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> > >>
>> > >
>> > _______________________________________________
>> > hibernate-dev mailing list
>> > hibernate-dev at lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev