JSR 310: A New Java Date/Time API

Discussions

Blogs: JSR 310: A New Java Date/Time API

  1. JSR 310: A New Java Date/Time API (11 messages)

    How to use dates and times is probably one of the first design decisions behind a programming language. And such is the case behind java.util.Date and java.util.Calendar which have been around since Java's JDK 1.0 and JDK 1.1, respectively. JSR-310 is one of the latest initiatives to address 'the age' shown by these last Java classes that deal with dates and times, while still maintaining backward compatibility with them. Read the complete post 'JSR 310: A New Java Date/Time API' http://today.java.net/pub/a/today/2008/09/18/jsr-310-new-java-date-time-api.html

    Threaded Messages (11)

  2. Over-Designed[ Go to top ]

    This is a nice intention, but this new API seems to me a little bit over-designed. At the moment there are two importent classes for working with time: Date and GregorianCalendar. In the new API are much more different classes. I think for a comfortable API it is importent, that the set of classes is small, which a developer has to keep in mind. And it needs the right methods for your business cases. JSR 310 has some nice methods for real business cases, but I think the comfort should be higher. (Some points of the old API could give more comfort to developers.)
  3. Re: Over-Designed[ Go to top ]

    I want this add to my previous post: Any new date/time API must end up in a java.util.Date object. Almost all java applications store timestamps as a Date object. Further more, I took a closer look at the JavaDoc: Realy, realy over-designed! Sorry, but I couldn't tell you where to start for a simple business case in this bunch of classes. Sorry: I give a No-Go for JSR 310.
  4. You've got to be kidding.[ Go to top ]

    I took a closer look at the JavaDoc: Realy, realy over-designed! Sorry, but I couldn't tell you where to start for a simple business case in this bunch of classes.

    Sorry: I give a No-Go for JSR 310.
    Really, if you have ever tried to do anything with Date or Calendar you'd have realized just how broken they are. Several years ago we ran some performance tests and found one of our main bottlenecks was in DateFormat. We switched to Joda Time and never looked back. Date and Calendar are allowed only where they are required.
  5. Re: You've got to be kidding.[ Go to top ]

    Several years ago we ran some performance tests and found one of our main bottlenecks was in DateFormat. We switched to Joda Time and never looked back.
    Interesting. Well, performance issues is a point I understand. But I don't understand, why do you need so many classes? How many classes do you use in your Projects? I save timestamps, calculate new timestamps by durations and display timestamps in Websites (JSP) in my projects. How many classes do I need for this? (OK: If I could speed up my Web-Application, then I am very interested in Joda Time. But I don't think the JSR has any thing to do with performance, isn't it?
  6. Re: You've got to be kidding.[ Go to top ]

    But I don't understand, why do you need so many classes? How many classes do you use in your Projects?

    I save timestamps, calculate new timestamps by durations and display timestamps in Websites (JSP) in my projects. How many classes do I need for this?

    (OK: If I could speed up my Web-Application, then I am very interested in Joda Time. But I don't think the JSR has any thing to do with performance, isn't it?
    To give you an idea of what is wrong with Date and Calendar here is one link I found. Date: Java Glossary. There are lots of classes because there are actually lots of things you want or need to do with Date and Time handling. The Joda Time documentation illustrates many of them. For raw timestamps you don't need any Date classes, just a long. However, don't think that that timestamp actually tells you what time it is. Without a timezone it doesn't mean much.
  7. While timestamps and simple math may be sufficient for simple web application needs - more complex calendaring needs quickly leave the Timestamp class in the dust. Doing simple things like asking "how many days between two dates" is notoriously difficult using the built in date, time, and calendar objects in Java. Sure - taking the difference of the two timestamps, and then doing some math to divide it by a number of milliseconds representing a 24 hour period is do-able but it has some problems. If we're at 12:00 noon on 2008-09-26 (YYYY-MM-DD) and I'd like to know how many days between that date/time and 12:00 noon on 2008-09-30, I'll probably get the wrong answer using the difference of two time-stamps / 24 hours (in fact, I know I will). The correct answer would be 3 days; the simple math above would produce 4 days. Which while "literally" true - is _not_ how people interact with dates / times. In short - Java has great built in support for "instants" (e.g. timestamps) - but extraordinary poor support for things like durations, intervals, and periods. The team who worked on Joda Time has had significant input into the new JSR - I'd consider Googling them - and reviewing what that API does before passing judgment on the new spec. In short it solves a lot of problems with dealing with dates and date/time calculations - most likely in a less bug ridden fashion than many home-brew calculations produce.
  8. Ok, thanks to all. You give me a positive view to Joda. I promise to try Joda in some time. I am still sceptical for the JSR, but may be time will prove me wrong.
  9. Re: You've got to be kidding.[ Go to top ]

    By the way, the Joda Time API is very good documented. (The JSR 310 is not.)
  10. A No-Go?????[ Go to top ]

    I've been using Joda for at least 2 years now, and it is way to better and simple to use, specially when you have to do date/time/interval calculations (one of the apps where I've used it was a "electricity quality control" that had measures to the millisecond that we had to use in calculus). So please, go-go...
  11. Need Date without Time[ Go to top ]

    What is missing in the current Calendar and Date implementations, is a date that does not have a time component and therefore that does not depend on the timezone. To store a date like 2008-10-14 currently you will use either a string representation or a DateTime with a time of 00:00.000 (like java.sql.Date). The problem with the latter is, that if you change the timezone, the date will change to the day before with a propability of up to 50%, but might also change only in very rare cases. Example (from my memory): We used a java.sql.Date to store a date. The timezone was set to 'CET' (Central European Time). At some part of the application, the data were read with the timezone 'Europe/Berlin'. This looks pretty much to be the same, but it is not. Between 1946 and 1948 the russian military in East Berlin set a special daylight savings time of +2 hours. In our application the people born in summer of these years suddenly became one day older. This came up too late and the data went into production.
  12. I didn't see anything about making it easier to update daylight saving time rules. Using the current JDK you have to wait for Sun to issue an update. Using Joda, you can manually recompile the joda.jar using new rules from the tz database site, but this is still a bit too intrusive. How does JSR 310 deal with this problem?