Take the 2-minute tour ×

Although Joda is feature rich and more sophisticated than standard Java time, it may not always be the best thing to use. How do I decide if I should use Joda Time or Java Time in any Java code?

Is there some kind of guideline which tells us how to pick the right one depending on our requirements?

share|improve this question
Get the best of both worlds, by using the new Date & Time API included in Java 8. It's heavily influenced by Joda Time. In fact the main author is Stephen Colebourne, the author of Joda Time. –  Joachim Sauer Mar 17 '13 at 9:41
@JoachimSauer Has it appeared in a final release or this will happen when Java 8 will launch? –  m3th0dman Mar 17 '13 at 10:54
@m3th0dman: it will be included in the final Java 8 release, it's not yet been released. GA is currently scheduled for 2013-09-09. –  Joachim Sauer Mar 17 '13 at 11:10
add comment

3 Answers

up vote 26 down vote accepted

Joda Time is such an improvement over the Java time library that it is almost always the right choice, apart from the following exceptions:

  1. When it is difficult or undesirable to add third party dependencies to your project

  2. When its use in a public interface would cause issues, e.g. getting an ORM to handle both java and Joda time fields

However, in the case of 2) it would still be better to use Joda internally if possible.

The above things are worth keeping in mind, but should be rare. If in doubt, go with Joda.

share|improve this answer
Please tell me what "use Joda internally" means. I am a beginner and I don't know all these things. –  Jedi Knight Mar 18 '13 at 0:24
@Jedi Knight: it means the application uses Joda for its own logic and only converts to/from java.util.Date when it communicates with an external system that requires it. –  Michael Borgwardt Mar 18 '13 at 9:38
By 'internal', it could be internal to the application as a whole (as in Michael's example), but it could be internal to a class or just a particular method. Say for example that you have a utility method that takes two Java Date objects and calculates the number of working days between them, but it contains a bug. To fix it, it may very well be easier to rewrite that method using JodaTime instead but you may not be able to afford the time to refactor all the code that calls the method, so you leave the method signature unchanged. In this case you're using Joda "internally" in that method. –  Robert Johnson Mar 18 '13 at 10:04
add comment

The Java standard date API is so fundamentally broken that I have often considered simply adding Joda Time to the library extensions of the JVM so that it loaded on the classpath by default with the rest of the Java API.

If you have ever been tasked with retrofitting internationalization and time zones into a legacy Java application and have attempted to use the standard Java API alone, you will understand what I mean. I was able to turn thousands of asinine lines of code into less than a hundred. The productivity boost is inconceivable.

Further the standard Date API is not intuitive, where the fluid Joda API can be picked up in hours not weeks. Your analogy of trying to get to the island that is two miles away, is more akin to the following.

1) A motorboat that will get you to the island in only 6 minutes.


2) A makeshift bamboo raft tied together with vines during a hurricane steered by a crazy guy whose best friend is a volleyball.

As other answers have stated, the few drawbacks such as the ORM are even becoming non-existent as Hibernate now has plugins that allow for Joda type bean properties to be mapped to database date/time fields. JPA might also have an answer for this as well.

If your desire is for your application to have a minimalist footprint as a desktop application as it pertains to disk space then perhaps Java is not even the right language choice.

share|improve this answer
add comment

One more point: Java-Time (i.e. Date) is not ThreadSafe but JodaTime is. So JodaTime is preferred when requirements like

  • MultiThreaded Environment accessing the common resources
  • Centralized Time Synchronization like situations

Or else for simple applications Java-Time is okay.

share|improve this answer
Even DateTime is also not ThreadSafe, isn't it? Correct me if i am going wrong. –  vintesh Mar 18 '13 at 14:26
The vast majority of the Joda library, including the DateTime class, is immutable and therefore thread-safe. However there are a few mutable classes that are not thread-safe. See joda-time.sourceforge.net/faq.html#threading. –  Robert Johnson Mar 18 '13 at 16:28
okay heard that. Thanks for drawing attention. –  vintesh Mar 18 '13 at 17:05
add comment

Your Answer


