Date/Timestamp problem with Java: equals fails, workarounds?

arcsher · **Joined:** Sat Aug 12, 2006 10:09 am **Posts:** 2

There seems to be an historic problem with hibernate's date/time handling (see http://forum.hibernate.org/viewtopic.ph ... highlight=) but since this post does not suppose any possible solution, I'm looking for an solution to make following code work.

Example:

Code:

    project=(Project)hibernateSession.get(Project.class, projectId);
    project.setDate(new Date());
    hibernateSession.save(project);
    hibernateSession.evict(project);

// reread the same object instance
    Project currentProject=(Project)
          hibernateSession.get(Project.class, project.getProjectId());

The code creates an object, saves it with a modified date entry, and reloads another instance of it. Afterwards equals method will fail

Code:

currentProject.equals(project)==FALSE !!!

Analysis:
The problem is caused by the equals method of the date objects:

Code:

   project.getDate().equals(currentProject.getDate())==TRUE
   currentProject.getDate().equals(project.getDate())==FALSE

The mapping for date is type="timestamp", after rereading the object the class of the date object changed from java.util.Date to java.sql.Timestamp. Bad luck: the hashcode of both classes is calculated in the same way, so

Code:

(currentProject.hashCode()==project.hashCode())==TRUE

Consequence:
It matters where the objects come from, hibernate is not "transparent" when dealing with hibernated objects.

Question:
Has someone else had problems with hibernate's date handling? Which could be a good workaround, that has no other "side effects"?

Implement a HibernateUtil.dateEquals() method and modify all the object.equals-methods? (Dirty since object.equals will work, but other programmers using my api may experience the same strange problems as I)

Write special code into getter/setter do to the mapping? (Dirty since I thought that this is exactly what hibernate should be for)

Any suggestions welcome!

tenwit · **Joined:** Thu Dec 23, 2004 9:08 pm **Posts:** 2008

The dateEquals option is the best of what you suggest. Even better would be to correctly implement Project.equals to take advantage of your new knowledge, gleaned from gavin's entirely correct statement at the end of the thread you mentioned:

gavin wrote:

Note that no self-respecting code should EVER call equals on a Timestamp. Its almost as bad as for Float.

This is true for two reasons. One, to avoid exactly the problem you're currently having. Two, different DBMSs store dates and times to different precisions, none of which are as accurate as java (for example, MS SQLServer stores times accurate to one-third of a second, or accurate to three seconds, depending on whether you use datetime or smalldatetime data types).

All equals methods (of entities) that want to compare date fields should not use date1.equals(date2). They should use UtilityClass.areRoughlyEqual(date1, date2).

UtilityClass.areRoughlyEqual(date1, date2) is left as an exercise for the reader.