summary

Unexpected (changed) behavior of @Temporal(TemporalType.DATE) columns

Description

Hi there,

first of all, thanks for your continuing work for hibernate.

Hibernate 4.2.6 shows a new behavior regarding the handling of

@Temporal(TemporalType.DATE)
private Calendar refDate;

columns.

Prior to 4.2.6 the seems to be handled like:

Take the date from the database and treat it like midnight
Then convert it to the userTimezone

Now it seems to bee

Take the date from the database and treat it like midnight
Then convert it to the userTimezone
Strip the time

This results in a calendar with a very different value than before. Technically it's probably more correct, but apart from breaking stuff, it's quite a different and unexpected behavior than @Temporal(TemporalType.TIMESTAMP) columns.

A result from 4.2.5 and prior for a date column with the value '2013-10-15' was
// Hibernate 4.2.5
// Tue Oct 15 02:00:00 CEST 2013
that can be correctly converted to a Joda Local Date with forced UTC timezone using
new LocalDate(foobar.getRefDate(), ISOChronology.getInstanceUTC())
resulting in exactly 2013-10-15

Now hibernate 4.2.6 returns:
// Hibernate 4.2.6
// Tue Oct 15 00:00:00 CEST 2013

This is quite different date.

I'd vote to restore the old way as it is consistent with the conversion in TIMESTAMP columns.

At least the changed should have been in the release notes as it is very likely to break stuff.

I've created a little test case. You'll need a mysql datebase hibernate_tests for it.

https://github.com/michael-simons/possible_hibernate_426_bug_with_date

Thanks in advance.

Environment

Java 7, user.timeZone "Europe/Berlin", MySQL with UTC timezone

Activity

Show:

Michael Simons

October 23, 2013, 6:18 PM

Thanks, Brett.

The idea behind my proposal is based on the assumption that at least the MySQL JDBC driver

handles time correct
but converts them into the user JVM timezone

So the only way to be save with 00:00:00 is in UTC, therefore stripping is done there. Than the resulting value is converted back to the JVM timezone.

Regarding your comment https://hibernate.atlassian.net/browse/HHH-8617?focusedCommentId=54459&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-54459 i wonder why the TimeZone is EDT at all, because i set the default to something else in my test. Probably you're referring to use my proposal in the Calendar type, i guess.

But anyway, yes, there must be an hour (or hour and 30 minutes offsets, depending on the weird zones out there), in different zones in all cases there is a transformation from server UTC to JVM timezone in accordance with the JDBC spec.

I got that you want Hibernate JPA act like the JDBC spec but i also think that this is part of the problem (please, no offense, just my opinion).

Anyway, thanks for the discussion and again for looking into this.

Brett Meyer

October 23, 2013, 4:56 PM

Ok, we're conceding that this needs revisited, although I still don't think the solution you provided was 100%. I'm reverting and releasing 4.2.7.SP1.

Michael Simons

October 23, 2013, 7:29 AM

This way it's even more fun:

Works perfectly in Hibernate 4.2.5 and doesn't in 4.2.6. You cannot blame the user (or me in this case) for bringing any time into this test case.

Sorry, but your implementation just doesn't work out and i'd be more than happy to help.

Michael Simons

October 23, 2013, 5:58 AM

Brett, i thank for still looking into this.

If the timezone and the time components are so irrelevant, than please explain to my, why this fails:

This only works if i set the calendar to hlp.set(2013, 10-1, 15, 2, 0, 0), otherwise the date ends up as 2013-10-14 in the database.

So i don't think we're done here.

Brett Meyer

October 22, 2013, 7:05 PM

, in my opinion, your fix makes things worse. With Calendar-as-a-Date (or plain Date), foobar.getRefDate().getTime().toString() should return 00:00:00 in the users timezone. Nearly all JDBC drivers do this. Your test case's entity returns the following refDate toString on most JDBC drivers, both before and after is applied.

Tue Oct 22 00:00:00 EDT 2013

Obviously w/ your fix, an hour can be there depending on the offset. Like Steve said, what we were shooting for really is the expected behavior.