Should I Use Java Date and Time Classes or Go with a 3Rd Party Library Like Joda Time

Should I use Java date and time classes or go with a 3rd party library like Joda Time?

EDIT: Now that Java 8 has been released, if you can use that, do so! java.time is even cleaner than Joda Time, in my view. However, if you're stuck pre-Java-8, read on...

Max asked for the pros and cons of using Joda...

Pros:

• It works, very well. I strongly suspect there are far fewer bugs in Joda than the standard Java libraries. Some of the bugs in the Java libraries are really hard (if not impossible) to fix due to the design.
• It's designed to encourage you to think about date/time handling in the right way - separating the concept of a "local time" (e.g "wake me at 7am wherever I am") and an instant in time ("I'm calling James at 3pm PST; it may not be 3pm where he is, but it's the same instant")
• I believe it makes it easier to update the timezone database, which does change relatively frequently
• It has a good immutability story, which makes life a lot easier IME.
• Leading on from immutability, all the formatters are thread-safe, which is great because you almost always want to reuse a single formatter through the application
• You'll have a head-start on learning java.time in Java 8, as they're at least somewhat similar

Cons:

• It's another API to learn (although the docs are pretty good)
• It's another library to build against and deploy
• When you use Java 8, there's still some work to migrate your skills
• I've failed to use the DateTimeZoneBuilder effectively in the past. This is a very rare use case though.

To respond to the oxbow_lakes' idea of effectively building your own small API, here are my views of why this is a bad idea:

• It's work. Why do work when it's already been done for you?
• A newcomer to your team is much more likely to be familiar with Joda than with your homegrown API
• You're likely to get it wrong for anything beyond the simplest uses... and even if you initially think you only need simple functionality, these things have a habit of growing more complicated, one tiny bit at a time. Date and time manipulation is hard to do properly. Furthermore, the built-in Java APIs are hard to use properly - just look at the rules for how the calendar API's date/time arithmetic works. Building anything on top of these is a bad idea rather than using a well-designed library to start with.

SimpleDateFormat vs DateFormat vs Joda-Time : Which one should be preferred with Kotlin?

TL;DR

Undoubtedly, java.time, the modern Date-Time API, and part of the standard library, is the most recommended option as of now.

java.util Date-Time API and their formatting API, SimpleDateFormat:

The java.util Date-Time API and their formatting API, SimpleDateFormat (which extends java.text.DateFormat) are outdated and error-prone. It is recommended to stop using them completely and switch to java.time, the modern Date-Time API^*.

Joda-Time API:

Quoted below is a notice from the home page of Joda-Time:

Note that from Java SE 8 onwards, users are asked to migrate to java.time (JSR-310) - a core part of the JDK which replaces this project.

Moreover, Joda-Time API is not the standard API of Java; rather, it's a 3rd party library.

java.time API:

This is the modern Date-Time API and was introduced with Java SE 8, as part of JSR-310 implementation, to model ISO_8601 standards. You can learn about java.time API from Trail: Date Time.

---

^{* For any reason, if you have to stick to Java 6 or Java 7, you can use ThreeTen-Backport which backports most of the java.time functionality to Java 6 & 7. If you are working for an Android project and your Android API level is still not compliant with Java-8, check Java 8+ APIs available through desugaring and How to use ThreeTenABP in Android Project.}

Differences between java.util.Date and Joda Time APIs

Java's standard date and time classes (mainly java.util.Date and java.util.Calendar) have limited functionality and have a number of design problems. The fact that many of the constructors and methods of java.util.Date are deprecated is one indication of this.

Joda Time has a much better thought out API than what's available in Java's standard library. There are classes for timestamps with or without a timezone, classes for holding only a date (year, month, day) or only a time of day, classes for periods, durations and intervals, it supports the ISO 8601 format (which is the standard format in XML documents) and much more.

I'd use Joda Time as my standard date and time library in any project - there really is no reason to use java.util.Date and java.util.Calendar.

Note that in a future release of Java, a new date and time API will most likely be included that's going to look a lot like what's currently available in Joda Time; see Project ThreeTen.

Also see Why Joda Time? on the home page of the Joda Time project.

Also, I've seen conflicting info about whether Joda Time is part of the standard API. Is it standard or not?

No, it isn't part of the standard API.

Update (copied from the comments):

Java 8 is out now, and it has a new date and time API which is similar to Joda Time (see the package java.time). If you're using Java 8, then please use the new date & time API.

Are there any cons to using Joda-Time?

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.

Most Supported Java Date/Time Class

tl;dr

Use the ThreeTenABP library in work with earlier versions of Android.

Period.between(
    LocalDate.of( 2017 , Month.JUNE , 23 ) , 
    LocalDate.now( ZoneId.of( “Europe/Paris” ) )
)

Use java.time

The original date-time classes bundled with the earliest versions of Java were well-intentioned but are an awful ugly confusing mess. Always avoid Date, Calendar, etc.

Joda-Time was an amazing industry-leading effort to make a serious robust date-time framework. Its principal author, Stephen Colebourne, went on to use the lessons learned there to produce its successor, the java.time classes built into Java 8 & 9, defined by JSR 310. The Joda-Time project is now in maintenance mode, and migration to java.time is advised.

Much of the java.time functionality is back-ported to Java 6 and Java 7 in the ThreeTen-Backport project. That project includes a utility class for converting to/from the legacy types so your new code may interoperate with old existing code. Further adapted for earlier Android in the ThreeTenABP project.

For example, on the Java platform you would call:

java.time.LocalDate localDate = java.time.LocalDate.of( 2018 , 1 , 23 ) ; // January 23rd, 2018.

…whereas on early Android using the ThreeTen-Backport/ThreeTenABP projects you would call:

org.threeten.bp.LocalDate localDate = org.threeten.bp.LocalDate.of( 2018 , 1 , 23 ) ; // January 23rd, 2018.

Span of time

To calculate elapsed time as a span of time unattached to the timeline, use either:

• Period for years, months, days
• Duration for hours, minutes, seconds, and fractional second in nanoseconds.

---

More simply put…

About java.time

The java.time framework is built into Java 8 and later. These classes supplant the troublesome old legacy date-time classes such as java.util.Date, Calendar, & SimpleDateFormat.

The Joda-Time project, now in maintenance mode, advises migration to the java.time classes.

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

Where to obtain the java.time classes?

• Java SE 8, Java SE 9, and later
  
  
  • Built-in.
  • Part of the standard Java API with a bundled implementation.
  • Java 9 adds some minor features and fixes.
• Java SE 6 and Java SE 7
  
  • Much of the java.time functionality is back-ported to Java 6 & 7 in ThreeTen-Backport.
• Android
  
  • Later versions of Android bundle implementations of the java.time classes.
  • For earlier Android, the ThreeTenABP project adapts ThreeTen-Backport (mentioned above). See How to use ThreeTenABP….

Is there (still) any good reason to use java Date/Time Calender API?

I would say "no" but answers need more characters.

No; JodaTime is significantly better. In theory, JSR 310 will bring about the deprecation that should have come some time ago. We shall see.

Is it somehow possible to extend Joda-Time classes marked final?

You can wrap a final class into your own class, provide whatever operations you want, and provide "view" method which will return the original Joda-time object. Like that:

public class MyJodaExtension {

    private final DateTime dateTime;

    public MyJodaExtension(DateTime dateTime) {
        this.dateTime = dateTime;
    }

    public boolean myOperation() {
        return false;  // or whatever you need
    }

    public DateTime asDateTime() {
        return dateTime;
    }

}

With this approach you can even make your MyJodaExtension mutable and provide different instances of DateTime if you want (but I hope you don't, immutable classes are great).

As Nathan Hughes said, there is no way you can pass such "inherited" class to other libraries or any code that expects original Joda time class.

Java Date vs Calendar

Date is a simpler class and is mainly there for backward compatibility reasons. If you need to set particular dates or do date arithmetic, use a Calendar. Calendars also handle localization. The previous date manipulation functions of Date have since been deprecated.

Personally I tend to use either time in milliseconds as a long (or Long, as appropriate) or Calendar when there is a choice.

Both Date and Calendar are mutable, which tends to present issues when using either in an API.

---

Related Topics