Friday, November 19, 2010

Go ahead to part 2 of this articleHave you ever tried to persist a date with Hibernate, which is supposed tobe in a different time zone from the one of the system your applicationis running on? I'm pretty sure that you will get into trouble whiletrying this. There's a number of obstacles to pass. Let's get them onone by one and figure out appropriate solutions.

The SetupI'm using JBoss 5.1 with Hibernate 3 and JPA for this tutorial. The data base isMicrosoft SQL Server Express 2008 with the JDBC driver fromsqljdbc4.jar. Both, JBoss and SQL Server are running on the samemachine in time zone Europe/Berlin with Central European Time (CET) asactive time schedule. We want to persist a Date to the data base wich shows up there in GMT time.We will need two Java classes. First there's the entity data object to bepersisted to the DB. As we want to persist GMT date records, it is calledGMTDateEntity:

Now let's persist a date object to the DB using our two classes. For this example I will create a java.util.Date representing the 9. November 2010, 12:00h GMT which we want to store to the DB. Now we do something like this:

What happened? The time is shifted by an hour! This is because java.util.Date stores dates in a time zone independent fashion, but for SQL data bases there dosn't exists the notion of time zone independent dates. You can store date records to a SQL DBMS only with a specific time zone. So what Hibernate does, is using the time zone schedule of its JVM (which runs in CET) to convert the time zone independent java.util.Date to the time zone specific date string in our DB record. Because CET is one hour ahead of GMT, one hour has been added to our DB date.Unfortunately, there exists neither an Hibernate or JPA annotation nor any other simple way to tell Hibernate in which time zone to persist java.util.Date objects. So if we cannot set the time zone schedule of our JVM to GMT, we must figure out other ways to tell Hibernate what we want.

2. Obstacle: Hibernate doesn't use Calendar's time zone for readingThe sensible way for attaching time zone information to dates in Java is the use of java.util.Calendar. So let's tweak our entity class a bit and add a Calendar field:

cal.setTime(date); entity.setCalendar(cal); dateTestDao.persistGMTDateEntity(entity);//Now read back what we persisted, and store it againGMTDateEntity readEntity = dateTestDao.retrieveGMTDateEntity(entity.getPk());GMTDateEntity newEntity = new GMTDateEntity();//just to be sure we set the time zone to GMT againreadEntity.getCalendar().setTimeZone(TimeZone.getTimeZone("GMT"));newEntity.setCalendar(readEntity.getCalendar());newEntity.setDate(readEntity.getCalendar().getTime());dateTestDao.persistGMTDateEntity(newEntity);

The DB now looks like this:

What the hell?! Obviously we got a Calendar out of the DB which is different from the one we previously stored to it! And that's true. When reading from DB, HIbernate creates a completely new Calendar object, and uses the system's time zone again for converting the date.

3. Obstacle: There are solutions, but it won't be easy!

Well, if you're as naive as I am, you might just shout out: "Of cause it didn't work! We didn't tell HIbernate about the target time zone of our entity class!" And then you would go and tweak the GMTDateEntity like this:

Just to shorten this: It will not work! Hibernate uses Reflection to set the entity's fields, and when it comes to do so, the date conversion is already done. So instead of asking yout entity's field: "What kind of time zone would be welcome, Sir?", it just creates a new Calendar instance in system's time zone and squeezes the DB date into it.However, there are some more complex solutions to this problem, which I will explain in the second part of this article.