2

For years there's been a consensus to use Joda-Time or at least to not use the JDK classes (Date, Calendar, etc.) when working with dates and times, because the JDK components are broken.

Not to take anything away from Joda-Time, which I have used and can confirm is awesome, but I have to ask, did Java 7 in 2011 or any of its minor releases fix any of these problems?

I ask because all these years later there is a value in knowing if the JDK has been fixed and not making assumptions in either direction.

Basil Bourque
  • 303,325
  • 100
  • 852
  • 1,154
user1445967
  • 1,520
  • 4
  • 14
  • 30

3 Answers3

4

j.u.Date Deprecation

As stated in the correct answer by Ryan Carlson, some of the java.util.Date class' methods are deprecated but not the entire class.

Yes, you should certainly avoid the java.util.Date/Calendar classes except where required by other classes. They are badly designed and implemented. Try to do all your calculations and business logic using other, more competent libraries.

Joda-Time

Currently, you should be using Joda-Time 2.3.

Quick example…

// © 2013 Basil Bourque. This source code may be used freely forever by anyone taking full responsibility for doing so.
// import org.joda.time.*;
// import org.joda.time.format.*;

DateTime nowInParis = new DateTime( DateTimeZone.forID( "Europe/Paris" ) );
DateTime newDayInParis = nowInParis.plusDays( 1 ).withTimeAtStartOfDay();

Dump to console…

System.out.println( "nowInParis: " + nowInParis );
System.out.println( "newDayInParis: " + newDayInParis );

Convert to UTC/GMT…

System.out.println( "now in UTC: " + nowInParis.toDateTime( DateTimeZone.UTC ) );

When run…

nowInParis: 2013-12-28T03:20:35.331+01:00
newDayInParis: 2013-12-29T00:00:00.000+01:00
now in UTC: 2013-12-28T02:20:35.331Z

JSR 310

In the near future, Java 8 will become available with a new set of java.time.* classes defined in JSR 310. These classes are inspired by Joda-Time but are entirely re-architected. The java.time classes have similar concepts to Joda-Time but you definitely need to do some re-learning.

  • If available, use Java 8's java.time classes.
    Early releases of Java 8 are available.
    A back-port of these classes to Java 7 was begun, but I don't know the status.
  • If not available use, use Joda-Time.
    Joda-Time is still actively supported and continues to work in Java 8 as well as Java 7, 6, and 5. For Java 4 you can use the very similar v1.x.

Here's a nice article explaining Java 8 java.time.* classes, Java 101: The next generation: It's time for a change – Catching up with the Java Date and Time API, by Jeff Friesen.

Community
  • 1
  • 1
Basil Bourque
  • 303,325
  • 100
  • 852
  • 1,154
2

As far as I know, they are still considered "broken". According to the Java 7 API, most of Date's constructors and methods are Deprecated..

If I were you, I would continue to use JodaTime.

The Guy with The Hat
  • 10,836
  • 8
  • 57
  • 75
0

They're still considered broken by most / many for anything other than simple tasks. In short, keep using Joda time.

As for them being fixed, the "fix" is Java 8's new time classes - these "fixes" will never be retrofitted to the date / calendar mechanism currently in use, since it would break backwards compatibility for applications relying on the current mechanism working the way it does (however odd that may seem to some!)

Michael Berry
  • 70,193
  • 21
  • 157
  • 216