Are there any cons to using Joda-Time?

I want to convince the architecture manager to include the Joda-Time jar in our product.

Do you know any disadvantages in using it?

I think Joda-Time needs to be constantly updated because of the files that it includes. And that is a disadvantage. Maybe I am wrong.

Could you provide some clarity on the subject?

Solution 1:

I've had almost entirely positive experiences with Joda Time. My one problem was when trying to construct my own time zone (for legitimate reasons, I assure you :) I got some very weird exceptions, and the documentation wasn't very good for that particular use case.

However, for the most part it's been a joy to use - immutability makes code a lot easier to reason about, and thread-safety for formatters is hugely useful.

Yes, there are files to keep up to date - but at least you can keep them up to date. It's not like they contain things which were unnecessary with Java's built-in stuff, it's just that with Java's mechanism you just couldn't keep information like timezones up to date without significant hackery!

Basically, +1 for using Joda Time. The Java date/time API is one of the worst bits of the Java platform, IMO.

Solution 2:

In my opinion, the most important drawback in Joda-Time is about precision: many databases store timestamps with microsecond (or even nanosecond) precision. Joda-time goes only to milliseconds. This is not acceptable to me: all "data model" classes that I use need to reflect the full precision of the data in my database. Approximations or truncations of my data by a library just don't cut it.

Here is the reasoning behind the choice of millisecond precision, taken from the JSR 310 mailing list:

"Joda-Time chose to use milliseconds as it made conversions to Date and Calendar easier." - S. Colebourne

Easier for whom? The author of the library, one would assume... Incorrect design decision, in my opinion, when almost all databases store times to microsecond/nanosecond precision. The disregard for database values is worrying.

Solution 3:

The biggest issue that we had when using Joda Time was with integration with Spring and Tapestry, as they both wanted to use the built-in Date and Time. We were constantly writing wrappers in getters/setters for date and time: either we would store it as Joda Time and one set of getters/setters passed it through and the other would convert on the fly, and some classes stored it internally as a Java Date/Time, and the Joda getter/setter had to switch it on the fly.

Basically, it was a headache because the classes are similarly named, and unless you can get your entire architecture (including other libraries you're integrating) to switch to Joda Time, you are going to write more wrapper code than you are likely to save by using the Joda libraries.

Solution 4:

Parleys hosts a presentation by Stephen Colebourne about JSR-310, Mr. Colebourne the author of Joda-Time and JSR-310. He starts out by explaining the weaknesses of the standard date/time support in Java and why you'd want to use an alternative. It may be helpful to show this presentation to your architecture manager. I can't seem to deep-link

The reason Joda-Time updates its timezone file fairly often is because timezone data changes all the time, often on short notice (today on slashdot: leap second added on 2008-12-31) and not always scientifically motivated (e.g. I recall some pacific island state changed its time zone to be the first country to enter the year 2000).