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?

  • 5
    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. Mar 17 '13 at 9:41
  • 1
    @JoachimSauer Has it appeared in a final release or this will happen when Java 8 will launch?
    – Random42
    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. Mar 17 '13 at 11:10
  • 1
    Both Joda-Time and the original Java date-time classes are now outmoded by the java.time classes built into Java 8, Java 9, and later. Jan 9 '18 at 23:15

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.

  • Please tell me what "use Joda internally" means. I am a beginner and I don't know all these things. Mar 18 '13 at 0:24
  • 5
    @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. Mar 18 '13 at 9:38
  • 2
    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. Mar 18 '13 at 10:04
  • 1
    FYI, the Joda-Time project is now in maintenance mode, with the team advising migration to the java.time classes. See Tutorial by Oracle. Jan 9 '18 at 23:12

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, is also the main contributor for JSR-310, as can be seen on the GitHub repository associated with http://www.threeten.org/. By 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:


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.


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.

  • Even DateTime is also not ThreadSafe, isn't it? Correct me if i am going wrong.
    – vintesh
    Mar 18 '13 at 14:26
  • 3
    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. Mar 18 '13 at 16:28
  • 1
    Thread safety for java.time is implemented through immutability. See stackoverflow.com/questions/9303532/…. This works well for both simple and complex applications. Even the api doc states that "All the classes are immutable and thread-safe" (literally quoted from the second paragraph). The old java.util classes on the other hand have several issues. I realize that this answer refers to the latter, but important to make that distinction now.
    – YoYo
    May 29 '17 at 1:21
  • Not representing date times as immutable values is just insane. I know it's been fixed now but really what in the world were they thinking? Nov 27 '17 at 23:48

The java.time framework replaces both legacy date-time classes and Joda-Time

Update: The old date-time classes shipped with the earliest versions of Java are now legacy, officially supplanted by the java.time classes built into Java 8, Java 9, and later.

Date, Calendar, SimpleDateFormat, and the java.sql.* date-time classes should all be avoided. There is never a need to use these confusing, troublesome, poorly-designed classes. They are entirely replaced by java.time classes. Their only purpose now is for maintaining existing old code. When interfacing with old code, you can convert to/from java.time by calling new methods added to the old classes. For more info on converting, see: Convert java.util.Date to what “java.time” type?.

The Joda-Time project, now in maintenance mode, advises migration to the java.time classes. The Joda-Time project inspired the java.time framework. Both are led by the same man, Stephen Colebourne. You can think of java.time as an rewrite/redesign of Joda-Time, all new code but using what had been learned over the years from building the industry’s first comprehensive and sophisticated date-time library.

To learn more, see the Oracle Tutorial. And search Stack Overflow for many examples and explanations.

Much of the java.time functionality is back-ported to Java 6 & 7 in ThreeTen-Backport and further adapted to Android in ThreeTenABP (see How to use…).

The ThreeTen-Extra project extends java.time with additional classes. This project is a proving ground for possible future additions to java.time. You may find some useful classes here such as Interval, YearWeek, YearQuarter, and more.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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