Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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
up vote 28 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

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

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 – Robert Johnson Mar 18 '13 at 16:28
okay heard that. Thanks for drawing attention. – vintesh Mar 18 '13 at 17:05

Note that on the Joda-Time website it states:

The standard date and time classes prior to Java SE 8 are poor. By tackling this problem head-on, Joda-Time has become the de facto standard date and time library for Java. Note that from Java SE 8 onwards, users are asked to migrate to java.time (JSR-310).

The main contributor to Joda-Time, jodastephen, seems also be the main contributor for JSR-310, which can bee seen on the GitHub repository associated with Bye the way, jodastephen has also a SO handle ...

I think it is safe to state that we can feel comforted and safe with the new Date and Time API as provided in Java 8 onward.

Some additional references:

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.