Why is the Java date API (java.util.Date, .Calendar) such a mess?

Question

As most people are painfully aware of by now, the Java API for handling calendar dates (specifically the classes java.util.Date and java.util.Calendar) are a terrible mess.

Off the top of my head:

• Date is mutable
• Date represents a timestamp, not a date
• no easy way to convert between date components (day, month, year...) and Date
• Calendar is clunky to use, and tries to combine different calendar systems into one class

This post sums it up quite well, and JSR-310 also expains these problems.

Now my question is:

How did these classes make it into the Java SDK? Most of these problems seem fairly obvious (especially Date being mutable) and should have been easy to avoid. So how did it happen? Time pressure? Or are the problems obvious in retrospect only?

I realize this is not strictly a programming question, but I'd find it interesting to understand how API design could go so wrong. After all, mistakes are always a good learning opportunity (and I'm curious).

Answer 1

My 2 cents are that it was designed way back in the day when the designers of Java thought the whole world uses the Gregorian calender and didn't comprehend that the world is in fact larger than just the United States of America

Answer 2

Java's early APIs are nothing more than a product of their time. Immutability only became a popular concept years after that. You say that immutability is "obvious". That might be true now but it wasn't then. Just like dependency injection is now "obvious" but it wasn't 10 years ago.

It was also at one time expensive to create Calendar objects.

They remain that way for backwards compatibility reasons. What is perhaps more unfortunate was that once the mistake was realized the old class wasn't deprecated and new date/time classes were created for all APIs going forward. This has to some degree occurred with the JDK 7 adoption of a JodaTime like API but really it's too little too late.

Answer 3

Someone put it better than I could ever say it:

java.util.Date is a testament to the fact that even brilliant programmers can screw up. java.util.Calendar, which Sun licensed to rectify the Date mess, is a testament to the fact that average programmers can screw up, too.

(Can't remember who came up with it; please edit/comment with the original quote & source if you know.)

As for mutability, a lot of the early JDK classes suffer from it (Point, Rectangle, Dimension, ...). Misdirected optimizations, I've heard some say. The idea is that you want to be able to reuse objects (o.getPosition().x += 5) rather than creating copies (o.setPosition(o.getPosition().add(5, 0))) as you have to do with immutables. This may even have been a good idea with the early VMs, while it's most likely isn't with modern VMs.

Answer 4

Actually the whole Calendar (not sure why Date is like it is) stuff was written by IBM, and like many (most???) IBM products it's plain and utter crap. In short don't ever trust IBM. Every now and then IBM does come up with good products but so many times it's sad they use their clout rather than technical merit to influence technology.

Answer 5

Time is itself not easy to measure and to handle with. Just look at the length of the wikipedia article about time. And then, there are different understandings about time itself: a absoulte time point (as a constant), a time point at a certain place, a time range, the resolution of time....

I remember, when i saw java.util.Date the first time (JDK 1.0?) i was really happy about it. The languages i knew of didn't had such a feature. I didn't have think about time conversion etc.

I think it's mess, because everything that changes leaves a mess if you evolve from one level of understanding (XMLGregorianCaldender vs. Date) and requirements (Nanoseconds, past 2030) to higher level, but keeping the old untouched. And java.util.Date is not a Exception. Just look at the I/O subsystem or the transition from AWT to Swing...

And because of that, "we should sometimes press the reset button." (who said that, btw.?)