Joda-Time 1.1 released - Replacing JDK Date and Calendar

Discussions

News: Joda-Time 1.1 released - Replacing JDK Date and Calendar

  1. Joda-Time 1.1 has been released. Joda-Time provides a Java library for date and time handling including the ISO8601 standard. It completely replaces the JDK Date and Calendar classes, while still providing good integration. It is open-source software under the ASF2 license.

    This release fixes some minor bugs in v1.0 and adds various useful new methods on existing classes. Highlights (from the release notes) include:
    • new Partial class, allowing any group of datetime fields to be defined
    • new convenience methods for adding periods, such as plusDays(n) or minusHours(n)
    • YearMonthDay and TimeOfDay are now comparable
    • new methods to create a Period from two YearMonthDay or two TimeOfDay objects
    • new methods on Interval - gap, abuts and overlap
    • better handling of two digit years in formatting/parsing
    • added ISO formats for ordinal (dayOfYear) dates
    Hibernate and JSP integration are planned for the future.

    Major features of Joda-Time
    • Easy to Use - Calendar makes accessing 'normal' dates difficult, due to the lack of simple methods. Joda-Time has straightforward field accessors, like getDayOfWeek().
    • Extensible - Joda-Time supports multiple calendar systems via a plugin mechanism, which is much more extensible than the subclasses of Calendar. Currently supported calendars are ISO8601, GregorianJulian, Buddhist (Thai) and Coptic.
    • Comprehensive - Joda-Time includes classes for datetimes, dates without times, times without dates, intervals and time periods.
    • Advanced formatting - An advanced and extensible formatting mechanism is included, allowing input and output to string in a thread-safe manner.
    • Well documented. There is documentation in the form of a quick and full user guide, plus reference pages, FAQs and javadoc.
    • Tested. There is good test coverage, see the website, providing an assurance of quality.

    Threaded Messages (16)

  2. How long for Sun to start not including deprecated api in rt.jar? Such as date.

    Whale/Dolphin release?

    Is anyone using omg/corba packages on JRE SE for client side?
    Could that be just put in J2EE.

    Deployment has got to remove things we don't use.
    (Metal L&F). And to reduce download include what we need, like jGOodies Forms layout (most swing apps use it).
    It's the 80/20 rule, include 20% of code needed 80% of times.
    Flash 8 is 1 meg easy to download.
    And do we know what will users have to download for Dolphin just to RT client side?

    (Server side SDK and J2EE size does not matter).

    .V
  3. 1+ on removing corba, there must be a problem with legacy apps, but I think most developers would consider corba as an enterprise api.

    Congrats on the new release Stephen, looking forward to seeing the Hibernate types included (or as an additional jar) soon, I'm still using the ones I created a few months ago. Really useful API.
  4. Congrats[ Go to top ]

    Thanks for the enhancements especially the ones regarding YearMonthDay.This now means that i no longer have to convert between DateTime just do some computations.
    Otherwise a very nice library that works well with other frameworks e.g hibernate (through custom types), Spring MVC (through property editors), e.t.c.

    Conggrats on the release.
  5. Locale support[ Go to top ]

    Does anybody know the locale support available in Joda? For example with Date I can format it using long month names and it will translate the long month names for a given language. Also the JDK Date Calendar will provide default formatting for European style dates vs. American based on the locale passed in.

    I did some poking around the javadocs and I found that Joda's Timezone has the ability to output its long name for a given locale but I was having trouble finding other instances of localization support.

    Mike
  6. Locale support[ Go to top ]

    Looks very interesting. I've always had to write little helper methods to do things like calculate the number of days between two dates in Java, this sounds like it could ease some of my issues.

    Also, when performance profiling my application, in date-intensive operations, the Java API can actually become a bottleneck. It seems that the Java API recalculates the TimeZone offsets with almost every operation on a date or calendar, when this information should just be cached for a date object instance. I guess it's theoretically possible for a date object to be passed between time zones which would require the constant calculation of offsets, but it's quite annoying for the common case. It would be nice if you could label an object fixed to a time zone for this very reason.
  7. Re: Performance[ Go to top ]

    Also, when performance profiling my application, in date-intensive operations, the Java API can actually become a bottleneck.
    The performance of the JDK time zone class was one reason why we rewrote it. Also the JDK has quite a bit of annoying synchronization.

    Overall, we believe that the performance profile of Joda-Time is better than the JDK, although not every method is necessarily faster. But consistency under load is definitely good on the server.
  8. Re: Locale support[ Go to top ]

    Does anybody know the locale support available in Joda? For example with Date I can format it using long month names and it will translate the long month names for a given language.
    Yes, Joda-Time supports this. You can output any individual field directly:

    dt.dayOfWeek().getAsText(Locale.FRENCH);
    dt.dayOfWeek().getAsShortText(Locale.FRENCH);

    The pattern formats all support locales:

    dt.toString("EEE, dd MMM", Locale.GERMAN);

    You can also use the full formatting techniques with locales.

    DateTimeFormatter f = DateTimeFormat.mediumDateTime();
    f.withLocale(Locale.SPANISH).print(dt);
  9. Default Locale[ Go to top ]

    Standard java.util.Locale.setDefault() sets default locale for VM. Does Joda-Tome support a thread default locale?

    Suppose a scenario:

    I use a third party library in my Web application and the library uses Joda-Time. Each Web session has different locale. How to set default locale for each request processing?

    "a third party library" is any peace of code I use in a project, but changing the code is out of my responsibility. However, a library API doesn’t have a Locale parameter in all methods that potentially depends on locale.

    Nebojsa
  10. Default Locale[ Go to top ]

    Joda-Time does not support a thread-local locale, nor does it support a thread-local time zone. All localized operations in Joda-Time do support passing in Locale to override the default, so if you have your own thread-local Locale, you can pass it in directly. Any thread-local time zones can be passed in the same way.
  11. Hi,

    I started using Joda-Time 1.0 on my latest project, to try it out. So far I like it! Well done.

    In the past several projects I've created a domain-specific AppDate immutable value type for dates. I may still end up doing this in future, but I may use Joda-Time classes as the implementation, rather than Calendar.

    I've found that there is usually some amount of non-trivial domain-specific functionality in the value types, even in dates. For example, my current projects are in the energy sector, and we have TradingPeriods (half hour intervals) as well as the idea of a full day, and a BillingPeriod (full week). There are a bunch of methods in these classes relating to the others, e.g. AppDate has a getBillingPeriod() method. I prefer the interface of these value types to be designed around my domain, rather than overly "generic".

    On the matter of Hibernate support, I guess you can add it if enough people ask for it, but I don't see why all the fuss. Again, I would have thought most non-trivial projects would already have a number of domain-specific value types requiring a UserType to be defined for Hibernate mapping. In my projects I defined an ImmutableUserType base class, and so UserTypes such as AppDateUserType require only six pretty trivial methods.

    Regards

    John Hurst
    Wellington, New Zealand
  12. For example, my current projects are in the energy sector, and we have TradingPeriods (half hour intervals) as well as the idea of a full day, and a BillingPeriod (full week). There are a bunch of methods in these classes relating to the others, e.g. AppDate has a getBillingPeriod() method.
    With Joda-Time you have two choices for this. The one you've tried, where you hold references of Joda-Time objects internally. The second is to implement one of the Joda-Time interfaces directly, like ReadablePeriod or ReadableInterval. With this second choice, the base classes in the base subpackage can come in useful.
    On the matter of Hibernate support, I guess you can add it if enough people ask for it, but I don't see why all the fuss.
    Hibernate support will be separate from the main jar (partly because of the LGPL license of Hibernate, and partly because its the right archiectural design choice), and will just provide a basic solution for those who need it.

    Anyway, thanks for the comments (in fact thanks to all those who have commented on this thread!)
  13. Stephen,

    Why didn't you include joda time classes in commons-lang or haven't you created a commons-date project ?

    Gilles
  14. jakarta commons[ Go to top ]

    i agree, this should be a jakarta commons project.
  15. jakarta commons[ Go to top ]

    i agree, this should be a jakarta commons project.

    It could have been commons-time at various points in its life, but it just never ended up there.

    My question to you is why does it matter? Not all good open source is in jakarta-commons!
  16. why apache-jakarta-commons?[ Go to top ]

    My question to you is why does it matter? Not all good open source is in jakarta-commons!

    i agree, but "apache" has a good name in corporate development environment. if it is apache (i.e. jakarta, etc.) then it is acceptable to use w/o going through a review process.

    it isn't completely off-the-wall. i think it has less to do with quality and more to do with longevity -- the apache name is seen as something that will be around for a while, long after the original developers of a package have moved on.
  17. At last![ Go to top ]

    Good work releasing version 1.1, I've been waiting for an "official" release with the updates I added. Thanks again for a nice product, this has definitely helped us in cleaning up our code as well as giving performance improvements.

    Fredrik