Joda-Time 1.2 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. This release fixes some minor bugs in v1.1 and adds two new calendars as well as some useful new methods on existing classes. It is open-source software under the ASF2 license.

This release fixes a number of minor bugs in v1.1. There are also some new features:

• Islamic calendar system
• Ethiopic calendar system
• YearMonthDay/TimeOfDay factory methods to ensure exact field by field creation from Date/Calendar
• simpler conversion of a month/week etc to an interval - dt.monthOfYear().toInterval()
• convenient method for getting last day of month - dt.monthOfYear().withMaximumValue()

Release notes: http://sourceforge.net/project/shownotes.php?release_id=379940&group_id=97367
Download: http://sourceforge.net/project/showfiles.php?group_id=97367&package_id=104212

Hibernate and JSP integration are available from linked websites.

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. And the index of January is 1!
• 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), Coptic, Ethiopic and Islamic.
• 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.

Feedback
--------

As always, feedback is welcomed - whether bugs or reviews, good or bad! Only with input from the community can the library improve.

We're using it in production on several projects. It's not just a significantly better API than what we have in the standard JDK (which, to be honest, isn't very hard to beat), I'm convinced that it's one of the strongest date/time API's in any programming language, ever.

It would be great if Chinese lunar calendar is supported. It is often used by Chinese and Korean peple.

Currently we don't support the Chinese Lunar calendar. However, we are seeking to increase the calendars supported with each new release, so hopefully we can add it soon.

If you have code for this calendar, or good online web pages that will help. Even better is if you would like to code the calendar yourself :-) Please contact the mailing list for more info.

lunar calendar rules/program can be found here.

I heard that it is too complex to implement Chinese lunar calendar which works all the time. So, you use some pre-calculated lookup table.

Please take a look at the code of HappyDays:

http://jmjeong.com/?HappyDays

sol2lun.c and lun2sol.c contain conversion between solar calendar and lunar calendar, so you could get some hints from there.

HTH,
Trustin

I personally think Joda-Time *is* great, but it is too big for what it actually does. For server-stuff side, we don't care, but for client-side stuff I'd have to seriously wonder whether it makes sense to include this kind of library in my distribution. Just my 2 cents.

Maybe there is no way to shrink Joda-Time further (implementation sharing or something?)... so it's fine the way it is. But if there is a way, you should consider trying it out.

Gili

Maybe there is no way to shrink Joda-Time further (implementation sharing or something?)... so it's fine the way it is. But if there is a way, you should consider trying it out.Gili

The most commonly used classes in Joda-Time have so much dependencies on other internal classes that it is actually quite difficult to break the jar into several pieces. As Joda-Time expands to support more complex calendar systems (like Chinese) they can probably be distributed in separate jars. The currently supported calendar systems all derive from the same Gregorian-Julian algorithmns, so they're fairly small additions.

You can create a smaller jar without dropping features with a few simple changes. The jar that is distributed with Joda-Time runs javac with the debug option. Changing this setting to false in the ant build file frees up 96 kbytes. You lose both symbols and line numbers, however.

Also, about a quarter of the distributed jar file is filled with compiled time zone data files. The compiled format has already been heavily optimized, and further optimizations will likely yield little improvement. Reducing the set of available time zones, however, shrinks the jar.

It doesn't seem to support the Hebrew date.

It shouldn't be that hard to implement:

http://shamash.org/help/javadate.shtml

Yes, Hebrew is another calendar system that needs to be implemented. Its just a matter of having spare hours to code and test.

simply put, i hate jdk date and calendar classes. they are so bad i dont know where to begin.
however, we managed to get around most of the bugs and strange behavior.
what i would like is for the joda guys to make some kind of a list of examples where jdk classes act strange or buggy and how joda time fixes this.

i could not find such a list and i hope someone can make one or point me to where it is.

Try this on JDK 1.4:

TimeZone tz = TimeZone.getTimeZone(“Europe/London”);
Calendar calA = Calendar.getInstance(tz);
calA.set(1945, Calendar.JULY, 1);

Calendar calB = Calendar.getInstance(tz);
calB.setLenient(false);
calB.setTime(calA.getTime());

long millis = calB.getTimeInMillis();

Now change the year to 1946. Bonus points if you can figure out the reason why :-)

Can you tell me what the bug is?

TimeZone tz = TimeZone.getTimeZone("Europe/London");
Calendar calA = Calendar.getInstance(tz);
calA.set(1945, Calendar.JULY, 1);

Calendar calB = Calendar.getInstance(tz);
calB.setLenient(false);
calB.setTime(calA.getTime());

System.out.println(calA.getTimeInMillis());
System.out.println(calB.getTimeInMillis());
System.out.println(calA.getTime());
System.out.println(calB.getTime());

--

-773245210344
-773245210344
Sun Jul 01 12:39:49 CEST 1945
Sun Jul 01 12:39:49 CEST 1945


1945 -> 1946

--

-741705567813
-741705567813
Mon Jul 01 12:40:32 CEST 1946
Mon Jul 01 12:40:32 CEST 1946


Sun JDK 1.4.2_06 Win XP

Can you tell me what the bug is?

It is possible that they have now fixed this in JDK1.4.

The bug that you should see is that 1945 will throw an IllegalArgumentException, but 1946 works OK. Rather a strange effect!

The reason is that the GregorianCalendar hard codes a list of maximum and minimum values for each field. The DST_OFFSET field is limited to 1 hour. However in 1943, 1944 and 1945, the UK had 'double summer time' where we moved 2 hours forward in the summer instead of one. As a result this exceeds the limit in GregorianCalendar, and thus throws IllegalArgumentException (as lenient is false).

See http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4639407

See http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4639407

Hmmm, the bugs comment says that it is still present in 1.4.2_09 but I can't reproduce it with 1.4.2_06.
Maybe it's only visible if one has a 'british' OS and not in my german Win XP.

Anyone know how Joda compares with Eric Evans Time & money library? This could be an interesting study on how, or if, domain driven design outcomes differ from other methodologies.

Anyone know how Joda compares with Eric Evans Time & money library? This could be an interesting study on how, or if, domain driven design outcomes differ from other methodologies.

Last time I looked, TimeAndMoney was designed as a wrapper around the JDK classes. Underneath it uses Date and Calendar, and thus still suffers from JDK bugs and performance issues. TimeAndMoney is also still officially an Alpha product.

Anyone know how Joda compares with Eric Evans Time & money library? This could be an interesting study on how, or if, domain driven design outcomes differ from other methodologies.

Last time I looked, TimeAndMoney was designed as a wrapper around the JDK classes. Underneath it uses Date and Calendar, and thus still suffers from JDK bugs and performance issues. TimeAndMoney is also still officially an Alpha product.

Is there any reason why TimeAndMoney doesn't use Joda-Time as it's implementation? TimeAndMoney is trying to solve higher-level problems, and thus can compliment Joda-Time, which offers low-level features.

Better late than never... I think this quoate explains why Time and Money doesn't use Joda Time:

"If JodaTime had been known to us back in 2003, when we started timandmoney, we might have focused just on money, or on some other combination."
-- Eric Evans

There was a discussion about it on the DDD group a while back:

http://groups.yahoo.com/group/domaindrivendesign/message/2564

Date and Calendar is used so frequently in all programs but Suns JDK still doesnt have any simple way of handling it. why is it the case ? Its been 10 yrs now and they still dont know how to fix the date problem ? Even PHP, microsoft - VB, .net etc have a simple date - but not SUN.

i think the main problem is that the calendar and date classes are to "core" such that any minor change would impact each and every aplication around the world so this might be a reason for sun not to fix them.

i think the main problem is that the calendar and date classes are to "core" such that any minor change would impact each and every aplication around the world so this might be a reason for sun not to fix them.

There are so many core areas which keep on changing in every jdk version . Just because its core or critical doesnt mean it should not be fixed. As a language developer i would stress more on it to stabalize it and not ignore it. I dont agree with this comment !! no sense

i  love Date and Calendar

stork club new york