[hibernate-dev] HHH-11396 - Timezone handling

[Christian Beikov]

So you are saying that it should be the JDBC drivers responsibility to 
add the JVMs local timezone offset to the java.sql.Date so the 
normalization can subtract the offset again? I would be ok with that, 
but is it really the responsibility of the JDBC driver?


Mit freundlichen Grüßen,
------------------------------------------------------------------------
*Christian Beikov*
Am 14.03.2017 um 10:39 schrieb Jordan Gigov:
> What java.sql.Date does is wrong for many reasons (mostly because it
> extends java.util.Date which is a horrible API), but I think Vlad laid
> it out pretty well why it's a JDBC driver configuration problem and
> not a Hibernate problem. If you simply rely on the Java API to use
> handle it's l own TZ conversion without telling it any zones (which
> that JDBC URL tells it), the problem should go away. The driver does
> try to read the server's time-zone, though, so maybe using
> `useTimezone=false` in the JDBC URL is the right solution, but it
> certainly shouldn't be to try and appease every driver's individual
> quirks.
>
> Even MySQL's own API works under the assumption that LocalDate should
> be converted using the JVM's default time-zone.
> https://github.com/mysql/mysql-connector-j/blob/release/5.1/src/com/mysql/jdbc/JDBC42Helper.java#L50
>
> On 14 March 2017 at 09:38, Christian Beikov <christian.beikov at gmail.com> wrote:
>> Hey everyone,
>>
>> I'd like to get your opinion on something. We had this issues regarding
>> timezone handling which Vlad closed pretty quickly saying it isn't a
>> Hibernate problem and I generally agree, but still would like to know
>> what you think about it.
>>
>> So basically what we do in the LocalDateJavaDescriptor(and also in some
>> other places) is to use the value returned by java.sql.Date in some way
>> and pack that into the target type. In this case this happens behind the
>> scenes when invoking java.sql.Date.toLocalDate() but internally it just
>> calls LocalDate.of(getYear() + 1900, getMonth() + 1, getDate()).
>>
>> Now IMO the problem really is in java.sql.Date because it does a
>> timezone conversion. The user who created the issue HHH-11396
>> <https://hibernate.atlassian.net/browse/HHH-11396> pointed out he was
>> using a DATE column type because he wanted to have a simple date i.e.
>> year, month and date. When using java.sql.Date and the consumer is in a
>> timezone after UTC i.e. UTC+1, the calculations of java.sql.Date will
>> subtract that offset during /normalization/ and the millisecond value
>> will change by that offset. This means that a date in the DBMS that is
>> 2000-01-01 will become 1999-12-31 when the client is in UTC+1.
>>
>> One possible fix is to simply configure UTC for the consumer, then there
>> will be no timezone shift.
>>
>> I think what java.sql.Date does is wrong because a date has no time
>> part, so there shouldn't be any time shifts. We should workaround that
>> by shifting the millisecond value back when constructing a LocalDate.
>>
>> What do you think should we do? Does anyone maybe know why java.sql.Date
>> behaves that way?
>>
>>
>> --
>>
>> Mit freundlichen Grüßen,
>> ------------------------------------------------------------------------
>> *Christian Beikov*
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev