views:

1514

answers:

4

Hi,

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.

+6  A: 

Well, unless you intend to wait for Java 7, 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 headackes.

gizmo
+1. Joda Time is so much better it's not even funny.
Jon Skeet
JSR-310 may not make Java 7
oxbow_lakes
Definitly use Joda Time
CodeMonkey
Pros and cons? I've never used Joda time - would be interesting to hear what people like about it.
Max Stewart
+6  A: 

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
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
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
should *not* be reinvented by non-specialists, IMO.
Jon Skeet
For "Obsolete" I just meant "will be replaced"
oxbow_lakes
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
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
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
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
Jon Skeet
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
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
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
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
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
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
That is; non-invasive dependencies.
oxbow_lakes
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
+35  A: 

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
  • If/when Java 7 gains a similar library, you'll have a head-start on learning it, as it'll be similar

Cons:

  • It's another API to learn (although the docs are pretty good)
  • It's another library to build against and deploy
  • If/when Java 7 gains a similar library, you'll need to relearn some stuff
  • 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
Excellent description of Joda, thanks
matt b
+3  A: 

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.

Ant