Home > Java > JSR-310: A specification request to free Java from the date handling nightmare

JSR-310: A specification request to free Java from the date handling nightmare

January 31, 2010 Leave a comment Go to comments

JSR-310 is important. A JSR isn’t that sexy, I know, but this one is worth fighting for.

In order to set the context, here’s an old news flash: The date implementation in Java is a piece of crap.

The Java community has ranted about this madness since JDK 1.0. Java doesn’t distinguish between date and time, and manipulating dates is cumbersome and error-prone. The solution, introduced in JDK 1.1, was not to rewrite Date, but in order to ensure backward compatibility, simply wrap a Calendar around the Date object. Calendar itself introduced several more serious problems and consequently – even more frustration. There is simply no concept of points in time, intervals, or durations. Even calculating the days between two dates is not trivial. It should be. Not the least, Calendar forces you into a random integer jungle when manipulating dates. Take your pick, you have lots to choose from: HOUR_OF_DAY, HOUR, DAY_OF_MONTH, DATE, DAY_OF_WEEK, DAY_OF_WEEK_IN_MONTH.

If that is not enough, the guilty parties responsible for designing the calendar has taken Edsger W. Dijkstra perhaps a little too literally.

cal.set(Calendar.MONTH, 0)

…yields January. Yep, Calendar refers to months using a zero-based index. A long time ago, Dijkstra told all programmers to count from zero. While this is both true and important for counting and holding track of your internal indexing, it’s NOT for every single concept imaginable holding a number. The numeric representation of January is 1, and not 0. What internal index Calendar stores January at is not relevant. The offered solution is priceless. Let’s just provide yet MORE constants to choose from: cal.set(Calendar.MONTH, Calendar.JANUARY). The int possibilities are endless. This sums up to:

To make matters even worse, Calendar has proved broken as well. For instance:

What about the Date object? We are looking at a class having 4 out of its 6 constructors, and 20 of its 28 methods deprecated. Consequently, Date should be regarded as a deprecated class. The fact that it’s not, and to some extent still necessary is a clear indication that something is horribly wrong in the date handling department. Ok, I guess I could go on and on about ranting about this. Do a quick search on java+calendar+date+broken, and you’ll have enough reading material to keep busy for a while.

Along comes Joda Time. An early bug report from 2000 asks for a replacement, but is rejected by Sun. The replacement the bug reporter asks for is Joda Time. Originating from Google SITA ATS Ltd (thanks, Ben!), Joda Time seeks to solve all challenges related to date manipulation encountered with the infamous Date and Calendar constructs. Whereas there has been some criticism of Joda Time being too complicated, introducing around 100 new classes with several levels of inheritance and so on, Joda Time has matured into a date and time API that forms the basis for JSR-310.

At JavaOne 2008, JSR-310 was presented in detail. Although no commitments about inclusion was made, JSR-310 was suggested to be included in Java 7. JSR-310 continues several of the same concepts introduced by Joda Time, instants, durations and intervals. In addition, the JSR-310 lead, Stephen Colebourne, is obviously the right man for the job. His previous project was, you guessed it – JodaTime. Everything is not in its right place, however. In December 2008, Colebourne announces a delay. But Java 7 is delayed as well, and at Devoxx 2009, Sun announced the delay of Java 7 until Q4 2010 at the earliest. Stephen Colebourne noted November 30, 2009 that this delay could be the last opportunity for getting JSR-310 into Java 7.

Someone should pay this guy to get this done. Right now, the future of date handling in Java 7 is dependent on Colebourne’s development in evenings and weekends. But everybody can help out – read more here.

JSR-310 is a specification request worth fighting for.

Categories: Java Tags: ,
  1. Ben
    March 24, 2010 at 17:44

    Good write up. JSR-310 is worthy of all our support, and you’ll be pleased to know that Stephen’s employer, OpenGamma, recognises the value of this and is sponsoring his efforts to progress it: http://kirkwylie.blogspot.com/2010/02/opengamma-set-to-welcome-stephen.html

    Quick clarification: Stephen’s recognition of the need for a solution in this area, and the inception of the Joda Time project began as part of his employ at SITA (not Google!) – management of dates and times is of crucial importance to the travel and aviation sector, and Stephen’s work began to solve some of our ongoing frustrations with the Java implementation.

  2. trulsjor
    March 24, 2010 at 19:04

    Hi Ben! Thanks for your comment, and big kudos to OpenGamma for recognizing the importance of this JSR. Also thank you for your clarifiaction – I’ll update the post with the right originating company right away!

  1. February 1, 2010 at 06:23
  2. February 2, 2010 at 22:28
  3. September 3, 2011 at 16:17
  4. January 12, 2013 at 19:18

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: