Message Title

Michael Simons commented on an issue

Steve: I'm trying to handle a date. What I get from Hibernate is a Calendar (or a Date) instance that has in both cases time components. I don't want them, to be perfectly clear. The JDK has at this moment no timeless or better timezone less classes. So i try to convert it to a Joda LocalDate. This has a chronology but no timezone (a date has no such thing). This has been working fine so far.

What has happend since "ever" was that the JDBC driver (and or hibernate) converts perfectly nice UTC timestamps to whatever ZONE the vm is running in.

This zone ends up in the result of every @Temporal column and therefor also in Date columns.

What we have now is a date that cannot have a zone but has one thanks to the broken date class of Java.

Hibernate 4.2.6 strips the (unwanted) time info from the date after conversion from UTC to CEST (in the test case) and thus alters the date.

I know its only a date but i cannot instantiate a LocalDate correctly without using the single fields or a conversion to yyyy-MM-dd

Also in regard to your 2nd comment: I don't want any time but i want a correct instantiated date class. One solution would be leaving the zone alone, treating it as UTC and strip all time information to 0. Would be fine with me.

Apart from where did i say that the previous behavior did attempt stripping? I tried to describe what i think it's happening here.

Add Comment

Hibernate ORM /

HHH-8617

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 userTimez...

This message was sent by Atlassian JIRA