views:

764

answers:

3

My entities currently contain java Date properties. I'm starting to use Joda Time for date manipulation and calculations quite frequently. This means that I'm constantly having to convert my Dates into Joda DateTime objects and back again.

So I was wondering, is there any reason I shouldn't just change my entities to store Joda DateTime objects instead of Java Date objects?

Please note that these entities are persisted via Hibernate. I found the jodatime-hibernate project, but I also was reading on the Joda mailing list that it wasn't compatible with newer versions of hibernate. And it seems like it isn't very well maintained.

So I'm wondering if it would be best to just continue converting between Date and DateTime, or if it would be wise to start persisting DateTime objects. My concern is being reliant on a poorly maintained library.

Edit: Note that one of my objectives is to be better able to store timezone information. Storing just a Date appears to save the date in the local timezone. As my application can be used globally, I need to know the timezone as well. Joda Time Hibernate seems to address this as well in the user guide.

A: 

Dates shouldn't be stored using a high level of abstraction like, say, a string ("2009-08-07 07:43:19 ...") nor as Java objects. They should be persisted as milliseconds since the epoch. Both Joda time and the regular Java date time can give you the time in milliseconds since the epoch. Store the number of milliseconds elapsed and convert back to objects when you're reading back from your DB.

Persisting heavyweight Date objects instead of a long is a bit like using floating point numbers to represent monetary amounts: it's typically a huge code smell.

Webinator
This doesn't seem very helpful for non-object-oriented users of that database. No one would be able to query that schema and query for all the orders placed today. Normally I would agree with advice like this, but it seems too Java and object centric to me.
duffymo
Most (all?) databases have date abstractions...
Jack Leow
I've certainly considered storing dates as a long (millis since epoch), but I'd like to do basic sql queries and be able to see readable dates as well. Besides, some of my queries are doing date calculations that I don't think the DB could handle with long values instead of date values.
Tauren
+1  A: 

I think using the Joda DateTime as your bean property type is probably a good idea. You can then have Hibernate do the conversion and save the property as the native database date format.

I have personally used jodatime-hibernate and have not had a problem with it (we're using Hibernate 3.2.5GA).

If you have concerns about jodatime-hibernate, you can always use Hibernate's custom type mapping mechanism (which I'm sure is all jodatime-hibernate does).

Jack Leow
I'm glad to hear you are successfully using joda-time for bean properties. I'm using Hibernate 3.3 which is where it sounds like people are having troubles. But I believe you're right, joda-time is simply a hibernate custom type, so perhaps with some tweaks I can get it working.
Tauren
+1  A: 

Joda Time Hibernate can be used with recent Hibernate releases - you may need a little bit of tweaking your dependency graph thats all (e.g. setting exclusions). Can I also suggest you look at User Type, which I have released onto Sourceforge. This provides User Types for Joda Time which aim to avoid the client offset issue you mentioned. I would welcome any feedback you have on that project. https://sourceforge.net/projects/usertype/files/

Regards Chris.

Chris Pheby