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?

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.

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.

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.

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).

In the past, I've encountered companies that didn't want to incorporate third party open source software, or at least required the company lawyer to certify that the license wasn't going to expose them to any sort of liability or have a viral effect on their product.

As with any third party libraries, you should probably put it into source control so you can find the version that you shipped with particular releases of your code in case something goes wrong.

The choice of milliseconds for the underlying time continuum is good for implementing calendars of antiquity, and special calendars. Unlike many counters, the 64-bit millisecond counter has good range coverage for calendars of antiquity, with rollover properties in excess of +/- 260 million years.

It does not handle leap seconds. This is a good thing. A smooth transition is proposed by the atomic clock folks to allow systems that do not deploy leap seconds to incrementally adjust their clocks over 100 seconds to accommodate the leap second correction.

Maintenance of timezone tables will also be an issue.

The underlying continuum also allows an old French calendar and clock that divided a day into 10 intervals called metric time instead of 24 hours. The classic Chinese calendar divides a day into 100 increments, each just over 14 minutes in length. All of these calendars can be implemented and coordinated on the underlying millisecond time continuum.

The main issue with it is vendor lockin at least until it becomes part of the standard.

For the most part I would use longs to store any business date information on a database. This gives me the flexibility to adjust the precision as I see fit. In most cases I just convert them to java.util.Date.

Time zones I would treat to be a presentation level issue than a data issue. This simplifies the database and increases portability since databases can represent temporals in different fashions.

The standard Calendar class provides me with some date manipulation functions which I convert to millisecond since epoch data.

As for nanosecond precision I would store that as an offset from 0 as a separate long column.