Skip to main content

Nominated project: Joda Time

14 replies [Last post]
cowwoc
Offline
Joined: 2003-08-24
Points: 0

Hi,

I would like to nominate Joda Time (found here: http://joda-time.sourceforge.net/userguide.html) for review by Sun. It seems to provide a rich and extensive replacement for Date and Calendar and replacing those two is certainly well-warranted.

What do you guys think? Feedback wanted :)

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
ccordier
Offline
Joined: 2004-01-05
Points: 0

There is a much simpler yet powerful Java datetime library: http://www.dprism.com/products/time/

wingetr
Offline
Joined: 2004-01-19
Points: 0

$175 for a single developer? Sorry - too expensive.

mgrev
Offline
Joined: 2003-08-12
Points: 0

$175 is a little more than a hour's work in a developed country. So if you can save more time than that by using a better library it's worth it.

$175 is nothing outside the Open Source/home fiddeling world.

IMO.

jwenting
Offline
Joined: 2003-12-02
Points: 0

let's make Java even more bloated.
Let's include all the Jakarta commons, the very name suggests they're in common use so they should be included.

There's nothing wrong with the existing classes for what I use them for...

markf
Offline
Joined: 2005-01-20
Points: 0

> There's nothing wrong with the existing classes for
> what I use them for...

By that logic, we should remove every class that you don't personally use, and never fix any bug that doesn't directly affect your code.

I like the first part of what you said though -- many parts of the Jakarta commons need to be integrated into the JDK.

dog
Offline
Joined: 2003-08-22
Points: 0

You say: should Joda Time replace Date/Calendar in java.util.

Obvious answer: yes!! in fact anything would be better than the current (mostly deprecated) mess!

However, what are the alternatives? I remember seeing some IBM classes for dates, are there others??

What I would like to see is:
- That it be easy to deal with dates
- That it integrate seemlessly with JDBC
- That it be easy to format dates
- That complex things can be done if necessary

Unfortunately a lot of APIs have this backwards.. making the hard easy and the easy hard.

scolebourne
Offline
Joined: 2003-06-20
Points: 0

For completeness, here are the links of datetime projects I know about:

http://timeandmoney.sourceforge.net - new, wrapper for GregorianCalendar

http://calendardate.sourceforge.net - new, wrapper for GregorianCalendar, only covers a date (no time) class

http://oss.software.ibm.com/icu/ - stable, from IBM, date handling is a development of the JDK Calendar class, thus has all of its problems still, has the widest range of calendars available

http://joda-time.sourceforge.net - the one I look after

There may be others....

lucretius
Offline
Joined: 2003-06-17
Points: 0

Here's another library that deals with dates only, not times:

http://mindprod.com/jgloss/bigdate.html

scolebourne
Offline
Joined: 2003-06-20
Points: 0

Joda-Time has always been designed to some degree with an eye on being included in the JDK (by using interfaces etc.). However, there would undoubtably be some challenges in achieving the integration.

A key point would be to preserve some of the gains made, such as easily pluggable calendar systems, and updatable time zone information.

I'd also love to hear any more comments on the design, good or bad.

Re the Instant class, it does indeed have a method to get the chronology, but that is always ISO UTC, and users should not be overly concerned with it. (Most users will never call methods on Chronology themselves.)

This fitted best with the fact that the long millisecond value is UTC based. Basically, we gave users the choice of a simple class Instant with no reference to fields (like dayOfWeek) or DateTime which does reference fields.

Stephen Colebourne
Creator, Joda-Time

mthornton
Offline
Joined: 2003-06-10
Points: 0

I can understand DateTime (and MutableDateTime) having chronology and timezone properties, but in my view ReadableInstant ( and therefore Instant) should have neither.
Also why have both the plus/minus methods and the withDurationAdded versions?

scolebourne
Offline
Joined: 2003-06-20
Points: 0

There is a case for saying that ReadableInstant should not have a chronology or time zone. However, the millisecond instant that the Instant class stores IS relative to a point in the datetime continuum, and that point is defined by UTC. Thus, it is not unreasonable for an Instant to reference UTC.

There is also no memory overhead with defining it relative to UTC, as the Instant class doesn't store a reference to the chronology or time zone. So, we could remove the chronology and time zone from the interface, but at the expense of complicating many other areas and hiding what was actually going on behind the scenes.

The plus/minus and withDurationAdded methods are new for 0.98. The idea is that the most common cases (add/subtract once) have methods with 'nice' names that effectively 'flow' in your code. The complicated case is then handled by the withDurationAdded method (add/subtract n times).

See also http://timeandmoney.sourceforge.net for some other thoughts on dates and times from another group.

mthornton
Offline
Joined: 2003-06-10
Points: 0

Much as I dislike java.util.Date and related classes, I am not enthusiastic about Joda time either.

In my view the Joda most basic 'instant' is far too complicated. I would have made the simplest class just hold time in UTC relative to some base date and basic string conversions to/from ISO8601 form. No Chronology or other issues.

I would however include a table of the leap seconds that have been declared to date and a mechanism to update this data via some url.

mgrev
Offline
Joined: 2003-08-12
Points: 0

+1 !!!

archangel
Offline
Joined: 2003-07-01
Points: 0

Replace Java's date/time classes with Joda? Hell yeah! Java's Date classes are terrible beyond belief.

I've never been able to understand how it is that so much of the Java Foundation Classes have been so well designed but then every now and then there's a real boo boo (Stack being a subclass of Vector for example).

There would be some integration issues (JDBC etc.), but I really think it's worth it.