Date4j is a new Java library for dates and times. Its available at www.date4j.net.

It was built out of frustration with both the JDK classes, and dissatisfaction with the JodaTime library. Date4j is open source, with a BSD license.

Important aspects of date4j :

• a single public, immutable class called DateTime handles parsing, formatting, and date-time calculations
• compatible with the date-time model used by most databases - a simplified 'proleptic' Gregorian calendar
• nanosecond precision
• no explicit time zones are used

Many will be surprised at the lack of explicit time zone. For more information as to why this design was intentionally chosen, please see www.date4j.net.

- John O'Hanley

Why not make suggestions to the JSR310 team instead of reinventing the wheel, they were already asking for help a couple months ago: http://www.theserverside.com/news/thread.tss?thread_id=44248

"Why not make suggestions to the JSR310 team instead of reinventing the wheel..."

This isn't reinventing the wheel. The two libraries are quite distinct. From the number of classes, to the overall approach, to the very mental model used to represent a date-time (time-line-instant-plus-time-zone versus immutable-with-no-time-zone), these are like night and day (if you'll pardon the pun....)

Or, you can look at it this way : this library does indeed form a suggestion to the JSR 310 team - a suggestion already implemented in software.

"immutable-with-no-time-zone" .. I dont know why this is supposed to be something big and convenient. I think this is where things go wrong. I went through the Date4J justification on TimeZone, and I think some of them are weak. Other points they have made efforts to make it intuitive and thats good.

But the "Immutable - No TimeZone"; neither practically helps. They have given analogies on how the DB stores the dates; and due to to that you have to maintain the state of the time zone on your own. Even, though they have provided to play with timezones the fact remains you need to maintain it in some other object and relate the two. Perhaps create a wrapper object that will maintain "DateTime" and "TimeZone". (Poor)

Immutable sounds fair though ..hmmmm! (That time zone thing relaly spoilt my mood so everything looks red now heh)

Sorry, wrong link:  http://www.theserverside.com/discussions/thread.tss?thread_id=59624

Your point is well taken. But you know, a bird in the hand is worth two in the bush.

The fact is, JCP moves slowly, and sometimes this industry just needs someone to 'get it done.' So, it's great to see a team taking the bull by the horns and getting something implemented now, rather than sitting on a comittee and talking about it.

Furthermore, I'm sure after looking at this, the community will get some good direction on how things should be done, and perhaps, even some discussion on how it shouldn't be done. These projects drive the industry forward by cutting the first path, and making it easier for others to follow in their footsteps.

I think this may be on the right track but I think it is still lacking in a few ways.  I appreciate that timezones are difficult to deal with but I'm not sure you can ignore them.  I've had bugs caused in the past because we had an application running in different parts of the world and ignored timezones.  You would end up with things like parent records in the database with creation dates that were later than the child creation dates e.g. parent record created in Germany and the child in Hawaii.

The other thing that this lacks is the ability to work with dates and ignore the times.  This may be mitigated somewhat by ignoring the timezone but I think it's still messy.  The time is usually only important with regard to determining which day an event occurred on.  Since date logic that I deal with is calendar date (only) based and deals with complex business rules around periods of days, I've found it necessary to define my own 'Day' class Period and PeriodSet classes.  One of the key features of the Day class is that non-existant dates must be supported.  I've yet to find a package that meets these needs.  When I look at or ask about how others have dealt with these problems, they stick to date or integer based dates and use procedural approaches.  This tells me that there is an unmet need for this kind of thing.

When I first saw this story I thought, Oh great, here's the Not Invented Here fad for 2010! We're gonna see 10 new date/time frameworks to go with our logging frameworks, mocking frameworks, web frameworks and behavor-driven-design frameworks.

But looking at www.date4j.net, this guy actually has a lot of good points. And the simplicity is appealing! I might be able to use this library without having to consult the JavaDoc for ten minutes every time, unlike Joda-Time.

Regards

John Hurst

When I first saw this story I thought, Oh great, here's the Not Invented Here fad for 2010! We're gonna see 10 new date/time frameworks 

Actually, I've build my very own date/time framework too! It's called Time4J. It's very fast, super elegant, and extremely easy and intuitive to use. In the real time is pretty easy, why does it have to complicated when using computers?

My API had just *one* class. Yup, *one* class; com.time4j.Time.

I'm currently preparing a comparison document that compares time4j with the JDK time (easy win), Joda time and now I'll consider this Date4j lib too. I'm still working on it, but from the looks of it, time4j wipes the floor with date4j! :P

"The other thing that this lacks is the ability to work with dates and ignore the times. "

Not sure what you mean by this exactly. Date4j handles dates-only. If a time portion is present, and you want to ignore it, then there are methods for doing that as well.

"The other thing that this lacks is the ability to work with dates and ignore the times. "

Not sure what you mean by this exactly. Date4j handles dates-only. If a time portion is present, and you want to ignore it, then there are methods for doing that as well.

Sorry.  Didn't notice that.  You might want to advertise this more.  It's a very desireable feature IMO.  If it were me, I would create a type for a Date but that's a style thing, I guess.  Personally,  I think this is the most useful thing about the library.

I really don't get the timezone thing, though.  All Java dates use UTC internally.  The timezone really just modifies the way it is displayed.  Sure, the API is terrible but I fail to see how ignoring the timezone solves anything.  If I care about the time, I have to care about the timezone.  Most of the time what I've seen is that small businesses think they can ignore the timezone and if/when they expand, they have to go back and fix their stuff to take timezone into consideration.

"I really don't get the timezone thing, though.  All Java dates use UTC internally.  The timezone really just modifies the way it is displayed.  Sure, the API is terrible but I fail to see how ignoring the timezone solves anything.  If I care about the time, I have to care about the timezone."

Some apps can ignore the time zone, some can't.

With JDK classes, you don't have any choice, since the time
zone is always implicit.
 
With date4j the time zone is always explicit, never hidden inside anything. That is, when time zone operations are needed, date4j has methods to let you change a date-time explcitly from one time zone to another. 

Note that many databases (MySQL, SqlServer, DB2) don't have any
data types for storing time-zone/offset at all.

The focus of date4j is trying to find a sensible way of storing
and retrieving dates/times from a database.

These points are presented at length (and in a better style!) in the date4j documentation.

"I really don't get the timezone thing, though.  All Java dates use UTC internally.  The timezone really just modifies the way it is displayed.  Sure, the API is terrible but I fail to see how ignoring the timezone solves anything.  If I care about the time, I have to care about the timezone."

Some apps can ignore the time zone, some can't.

With JDK classes, you don't have any choice, since the time
zone is always implicit.
 
With date4j the time zone is always explicit, never hidden inside anything. That is, when time zone operations are needed, date4j has methods to let you change a date-time explcitly from one time zone to another. 

Note that many databases (MySQL, SqlServer, DB2) don't have any
data types for storing time-zone/offset at all.

The focus of date4j is trying to find a sensible way of storing
and retrieving dates/times from a database.

These points are presented at length (and in a better style!) in the date4j documentation.

I looked at the the documentation but it still doesn't make sense.  The time zone in a Java Date is not implicit.  The actual milliseconds is always free of a timezone.  By ignoring the timezone you are making it implicit in that the values you are storing cannot be understood properly without knowing what timezone they were created in.  For example, if I create a record on a computer in Arizona I will persist a different value than in Nevada iff it's DST.  Even if you know which state the computer was in, you have to consider what year the record was created to determine what the universal time was.  With Java dates, you get the same value in the DB no matter what timezone the client machine was created in (assuming the clock is correct.)  Even if you don't have machines in different timezones, you are going to have issues if you are storing records during the "Fall back" hour in areas with DST.  Since that hour exists twice on that day, distinguishing one from the other is difficult.  In UTC, there is no such issue.

When you say the database doesn't have a field for storing the timezone. I have to ask why it would need to?  If you save a Java Date to the database, you should store the UTC value in the milliseconds field.  The timezone is not part of the time in Java or anywhere else.  The timezone is only for interpreting the time.  It should not be associated with the data.  It should be applied at the client at the point of reading or writing the value.

What most people get wrong is that they don't set the default timezone on the DB and then create Date objects as if the times in the DB are UTC.

Excellent!

Just to clarify : an app that models a date/time with date4j may or may not choose to deal with time zones. You can go either way.

There is a method in date4j, of course, to convert a date/time from one time zone to another. However, the time zone values are passed as explicit parameters to a method - the time zones are never internally stored as private fields in date4j.

If your app/database needs to pay attention to time zones, then, with date4j you can certainly do so, by pairing a date/time column with a corresponding time zone column. Thus, you have the two items, but cleanly separated.

If find this style less ambiguous than using the JDK's classes. It's nice and boring -- I can see exactly what's going on, conversions by the database stay the heck out of my way, and there aren't any nasty suprises. That makes me happy.

Some will agree, some will disagree.

With this new Date4j framework, won't that complicate the already fragmented DateTime frameworks out  there? It would have made more sense if they had supported what's already out there and widely used than coming up with a new one.

Just a thought!

Henry Dominik

Senior Software Engineer.