When I have a DateTime field in a database do I have to use the Calendar type in my hibernate objects/mappings to retrieve the date and time. At the moment I am just using java.util.Date which, when persisting, will eat the time component and leave the date only.

Should I be using a Calendar type for datetimes or am I doing something else wrong?

Cheers.

Myk.

You can use Date and use type="timestamp" in your mapping

Thanks for the quick reply.

For anyone else reading this for the same problem the "timestamp" type used in the mapping file still means you can use java.util.Date in your objects AND use DateTime ( SQL Server ) column type for readability of the db.

Thanks again.

Myk.

This is not completly true!
Try the following sample code:



The output is:


... and you would expect both to be TRUE !

Using timestamps means your date comparaisons will work on the database but fail inside your JAVA application. Refer to http://java.sun.com/j2se/1.4.2/docs/api/java/sql/Timestamp.html for more information...

Well thats a known problem of java.util.Date and java.sql.Date/Timestamp. This is not a problem however if you stick to one of them, and do not compare them to each other. And after all this is not a Hibernate problem at all.

Not saying it is an Hibernate problem...

Unfortunately, your Java application - inside its business part - often uses java.util.Date objects. If you tell Hibernate to map them with timestamps, you must be ready to face some problems at other places in your code. And you won't notice it since java.sql.Timestamp inherits from java.util.Date...

According to me, the safest approach is to define your own DateTime UserType. This user type would convert from java.util.Date to java.sql.Timestamp when persisting your data.
This way you have the best of both worlds: timestamp precision in your database (meaning date + time) while having a 'normal' java.util.Date inside your code. No need to worry anymore.

I can paste the code of such UserType here if needed...

BTW: People with experience in writing JDBC code are propably aware of this issue, but the others surely not... Moreover Hibernate is there to shield ourselves from the JDBC particularities - too bad to be hit by such 'known' problem :-(

Hello? Of course using type="timestamp" means you can use java.util.Date in your code and have hibernate convert them to java.sql.Timestamp when persisting. Just take a look at the source of net.sf.hibernate.type.TimestampType

TimestampType contains the following:



Which means it will return java.sql.Timestamp instances;
Which means all other comparaison you will made with java.util.Date will fail.

That's my point: I want to have Date/time precision in my persistent store AND be able to compare the retrieved data with other java.util.Date instances...

You won't have any problem if you are using java.sql.Timestamp everywhere in your code...

Oh yes, you are right, sorry, I did not notice that. That could really produce some nasty bugs. However I can't really think about a way around that ... if we just return a java.util.Date we will break code for everybody actually using java.sql.Timestamp and will loose nanosecond precission. It all comes down to that crappy implementation in the java API. That hierarchy is really broken ...

probably the cleanest way would be to create two seperate types for mapping java.sql.Timestamps and java.util.Dates - don't know, really

That's what I propose: creating a DateTime type that can be used in addition to the already existing ones. Since it doesn't exist yet - you won't break any existing code ;-)

This DateTime would behave the same way as the TimestampType except that its get() method would convert the timestamp retrieved from the resultset back into a java.util.Date...

I have put this to JIRA at HB-681 to keep it and have gavin find a nice solution to this :)

Negative. The current solution is perfect.

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