147

I'm creating a web based system which will be used in countries from all over the world. One type of data which must be stored is dates and times.

What are the pros and cons of using the Java date and time classes compared to 3rd party libraries such as Joda time? I guess these third party libraries exist for a good reason, but I've never really compared them myself.

JodaStephen
  • 60,927
  • 15
  • 95
  • 117
  • 5
    To clarify some comments… While Joda-Time continues, its successor [JSR 310: Date and Time API](http://jcp.org/en/jsr/detail?id=310) is indeed scheduled to be part of Java 8 under the [java.time](http://download.java.net/jdk8/docs/api/java/time/package-summary.html) package. Oracle has a draft of a [tutorial](http://docs.oracle.com/javase/tutorial/datetime/index.html). JDBC 4.2 [will handle](http://openjdk.java.net/jeps/170) the new data types. – Basil Bourque Oct 28 '13 at 10:28

5 Answers5

197

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.
Jon Skeet
  • 1,421,763
  • 867
  • 9,128
  • 9,194
24

Well, unless you intend to wait for Java 8, hoping that they will implement a better API for manipulating date and time, yes, please, use Joda-Time. It's time saving and avoid many headaches.

Basil Bourque
  • 303,325
  • 100
  • 852
  • 1,154
gizmo
  • 11,819
  • 6
  • 44
  • 61
15

The answer is: it depends

JODA (and JSR-310) is a fully-functional date/time library, including support for use with multiple calendar systems.

Personally I found JODA to be a step too far in terms of complexity for what I need. The 2 principal (IMHO) mistakes in the standard java Date and Calendar classes are:

  1. They are mutable
  2. They mix up the concept of a Year-Month-Day from an Instant-In-Time

Although these are addressed by JODA, you'll find it quite easy to roll your own classes for YearMonthDay and Instant, which both use the java classes under the hood for actual "calendrical" calculations. Then you don't have to familiarize yourself with an API of >100 classes, a different formatting/parsing mechanism etc.

Of course, if you do need complete representation of different chronologies (e.g. Hebrew) or wish to be able to define your own imaginary Calendar system (e.g. for a game you are writing) then perhaps JODA or JRS-310 is for you. If not, then I would suggest that rolling your own is possibly the way to go.

The JSR-310 spec lead is Stephen Colebourne who wrote JODA in the 1st place, so will logically replace JODA.

oxbow_lakes
  • 133,303
  • 56
  • 317
  • 449
  • 2
    I'd say it's going to become deprecated for greenfield developement targeting Java 7 - which is far from obsolete, IMO. The main reason *not* to develop your own classes at all is that date and time handling is insanely difficult. Using the standard Java classes in a "definitely correct" way (cont) – Jon Skeet Feb 26 '09 at 10:10
  • 4
    is hard too, IMO. In addition, there's the way that DateTimeFormatter in Joda time is thread-safe, making that aspect much more pleasant. You *don't* have to learn the whole API, of course - just the bits you need. The docs make this relatively easy. The date and time wheel is one which (cont) – Jon Skeet Feb 26 '09 at 10:11
  • 16
    should *not* be reinvented by non-specialists, IMO. – Jon Skeet Feb 26 '09 at 10:12
  • For "Obsolete" I just meant "will be replaced" – oxbow_lakes Feb 26 '09 at 10:21
  • As for the "non-specialists" remark, I simply don't agree. You can quite happily live with a YMD and an Instant class, using SimpleDateFormat for all parsing and Calendar for all arithmetic. It is NOT difficult and I am not a specialist – oxbow_lakes Feb 26 '09 at 10:22
  • 2
    So when you use SimpleDateFormat are you carefully making sure you never reuse the same instance from multiple threads without locking? How confident are you about the order in which you do things with the insanely complicated Calendar class's arithmetic? Why not use an expert's knowledge? – Jon Skeet Feb 26 '09 at 10:26
  • 1
    Yes - I am not a moron. You are mistaking "an expert" for "not a moron". I've been coding Java for >10 years; I got that SDF was not threadsafe around 1999 – oxbow_lakes Feb 26 '09 at 10:50
  • 1
    If people don't actually read the API doc, the chances that they'll use it properly are roughly nil. The more complex an API, the more likely they are to *actually* be nil. If someone can't use the existing java Date classes, I struggle to understand why they'll be fine if they use JODA instead – oxbow_lakes Feb 26 '09 at 10:52
  • 6
    I'm not a moron either, but I've still had problems with the Java D&T APIs. They're painfully easy to misuse. The reason why people are more likely to be able to use Joda properly is that Joda is better designed - it *encourages* you to do the right thing. – Jon Skeet Feb 26 '09 at 10:57
  • My point about SDF was that using it properly and efficiently takes a fair bit of effort - you've either got to create a new one each time or use locking. Why not use an API which means you don't need to do that work to start with? Why invent your own *new* API when there's already one there. – Jon Skeet Feb 26 '09 at 10:58
  • 1
    Because it's got >100 classes and was developed by a 3rd party? I'm extremely wary of introducing such explicit dependencies into my code. – oxbow_lakes Feb 26 '09 at 11:05
  • 6
    I trust an expert over myself any day of the week when it comes to date/time APIs. It's not like this is some random 3rd party API with no-one else using it. The ">100 classes" argument is a straw man, because you obviously don't need to learn them all. – Jon Skeet Feb 26 '09 at 11:21
  • 3
    Although, I didn't mean that I didn't trust JODA lots of people are using Maven and Apache Commons Collections: It doesn't mean that they aren't cr@p of the highest order! Lots of people using it == good is also a straw man. What I meant was "I don't want dependencies unless I have to" – oxbow_lakes Feb 26 '09 at 12:08
  • 5
    I guess we'll have to agree to differ. Any trustworth date/time written by experts *and* well-designed, which avoids me having to do dirty work with time arithment, counts as a "must have" from my point of view. Over the last year I've learned to hate human time measurement with a passion. – Jon Skeet Feb 26 '09 at 15:43
  • We will have to differ :-) I would only take dependencies which I can isolate to one particular class (e.g. a Spring Dao implementation) or which aid in configuration (Spring again). I wouldn't want 3rd-party classes littering my own – oxbow_lakes Feb 26 '09 at 15:52
  • That is; non-invasive dependencies. – oxbow_lakes Feb 26 '09 at 15:53
  • 3
    i fail to see why JODA time is an invasive dependency - does it bring in a whole host of new transitive dependencies? i dont think it does. Plus i trust library code over own code - as there were less eyes looking for bugs in my own code vs library code (opensourced ones i meant). – Chii May 26 '09 at 11:04
  • 5
    Rolling your own when Joda exists is a simply terrible idea. Just don't do it. It's true that Joda has dozens of classes that you're not going to use, but the answer to this is quite simply - don't use the ones you don't need. There are so many things that can go wrong with writing your own library of this type - the amount of effort you're going to have to put in is huge, both in development and in testing. Or, you can just add one library. Then, Joda has the added benefit that new recruits to your team may have used it before, but they won't have used your homegrown library. – Dawood ibn Kareem Jan 27 '14 at 19:07
  • I know, it is a very old post but from the perspective of being nine years later, how the state of Joda-Time is, well: You have tried to argue against Joda because it is a "fully-functional" library (what you didn't like), but Joda has been and is very limited`. It has never supported many calendars (too difficult with the design of Joda), and many chronologies like Hebrew never, too (although many people still believe this myth). Indeed, the reputation of Joda goes far beyond its real capabilities. But if you want to see how a (more) featured lib looks like then have a look at my lib Time4J. – Meno Hochschild Feb 07 '18 at 16:29
7

You should use a Joda-Time library, because:

  1. Joda-Time supports the ISO 8601 standard, which is a standard way of
    date representation.
  2. Adding and subtracting a day/month/year is easier in Joda-Time than java.util.date.
  3. An initialization by a give date is so much easier in Joda-Time.
  4. Joda-Time supports timezone as well.
  5. Joda-Time has a better built-in parsing. A wrong date like "2014-02-31" is thrown as an error: Exception in thread "main" org.joda.time.IllegalFieldValueException: Cannot parse "2014-02-31": Value 31 for dayOfMonth must be in the range [1,28].

You may like this page for more details: http://swcodes.blogspot.com/

Basil Bourque
  • 303,325
  • 100
  • 852
  • 1,154
Guest
  • 71
  • 1
  • 1
7

It all depends on what you are doing with the dates. If you are simply persisting them, them Java's built in Dates will probably do all you want them to. However if you are doing extensive time date manipulation, you're probably better off with Joda.

Anthony Roy
  • 1,835
  • 3
  • 15
  • 16