Error in saving Calendar field in DB2
Description
Activity
John ZhangMay 16, 2005 at 5:59 AM
Mr. Gavin King, I have to say it is very surprise and regretable to see your comment. I don't want to say anything more but I still want to state my points.
I re-write my test case and the FACT is:
create a object with Calendar attribute, print out the time in milliseconds and save the object to local database
close the session
open another session
load the record persisted in the first step and print out the milliseconds
finally, I get a different milliseconds in the Calendar object
I don't mind if you still insist it is correct or more corrective. From my point of view, this kind of saving 1 but getting 2 later on is definitely an undesired behaviour.
For the sake of your bandwidth, I won't say more.
GavinGMay 16, 2005 at 4:52 AM
Stop wasting bandwidth!
I rejected this and told you HB3 behavior is correct (yes, it is different to - more correct than - HB2.1).
I'm not changing anything.
John ZhangMay 16, 2005 at 4:39 AM
More findings:
I check my DB2 database and find more timestamps didn't get persisted correctly using Calendar type. It keep decreasing by 1 hour every time after it gets updated. And I checked the lastUpdateTimestamp (versioning column) of my table and all happened since last week after I upgraded to 3.0.x. I have been using my application for a long time since Hibernate 2.1.6, and I didn't have this problem before.
It should not be relevant to JDK cos I have been using the same version of JDK for a long time. Same thing for the database and jdbc driver. So the cause may be inside Hibernate or the libraries it depends on.
John ZhangMay 16, 2005 at 4:05 AM
Answers to Max:
what does "is not right" mean ?
It means wrong.
what i see is someone that stores and view the dates with a different timezone ...
My test case stores 1916 to 1918 in the same transaction, and then I check the database using DB2 tools. Everything is done in my computer. Nobody touches the timezone.
you at least need to attach the code that works in H2 and what fails in H3 in a runnable testcase (hopefully with proper assertions so we can see what you actually expect)
I think that's a very simple test case and anybody playing with Hibernate should have that kind of program, so ...
John ZhangMay 16, 2005 at 3:59 AM
Thanks for the comment, but ...
As you can see in the code, I didn't set or change the timezone in the loop, so the timezone should remain the same through the test case. But the results in database are obviously different. Even I manually change the timezone of my computer and run the test again, it gets the same result.
And it is not related to day light saving plan, since data wrong in 1917 but right in 1918 for the same month and date. If you try the November or December for some other years, which is beyond the day light saving plan, the behaviour is still not consistent. Sometimes right, but sometimes wrong.
I found this because my application ran very well in Hibernate 2.1.x, but immediately after I upgrade to Hibernate 3.0.x, some function broke.
My expected behaviour is so simple. The persistance for Calendar type should be consistent. For the same month and date, it shouldn't differ from year to year. Maybe I am wrong, but if that's the case, I think the Calendar type should be dropped in Hibernate mapping, since user may experience uncertain results.
Error in saving Calendar field for earlier years in the last century.
I have a class with a java.util.Calendar and java.sql.Timestamp field and persist it into DB2 8.1.3. The data types in database are both timestamp. I use the same time value for them and persist them together. Timestamp field is always correctly saved, but not always for Calendar field.
My mapping file is:
...
<property name="creationDate" column="creation_date" type="java.util.Calendar" />
<!-- using calendar or calendar_date has the same result -->
<property name="lastUpdateTimestamp" column="lastUpdateTimestamp" />
...
My test program is something like this:
for (int i=1916; i < 1920; i++){
TestObject bean = new TestObject();
bean.setPrimaryKey;
Calendar date = MyDateConverter.stringToCalendar(i+"-06-01-00.00.00.000000", "yyyy-MM-dd-HH.mm.ss.SSSSSS");
bean.setCreationDate(date);
bean.setLastUpdateTimestamp(new Timestamp(date.getTimeInMillis()));
session.save(bean);
}
After session finishes, I check the content in database and get something like this:
CREATION_DATE LASTUPDATETIMESTAMP
-------------------------- -------------------------- 1916-05-31-23.00.00.000000 1916-06-01-00.00.00.000000
1917-05-31-23.00.00.000000 1917-06-01-00.00.00.000000
1918-06-01-00.00.00.000000 1918-06-01-00.00.00.000000
1919-06-01-00.00.00.000000 1919-06-01-00.00.00.000000
Data before year 1918 is not right.
If you try more combination of different years and months, you will see the problem does not only happen before 1918, but also for 193x, 195x and more decades.
This problem doesn't occur in Hibernate 2.1.x.