Tapestry Training -- From The Source

Let me help you get your team up to speed in Tapestry ... fast. Visit howardlewisship.com for details on training, mentoring and support!

Friday, August 22, 2008

Stupid DateFormat

Working on some bugs related to the DateField component. Did you know that (for US English, anyway) DateFormat.getDateInstance(DateFormat.SHORT) provides back a DateFormat equivalent to "M/d/yy"?

That's a problem, because it has a tendency to format Dates to be two digit years. When it parses those same strings, it ends up considering the date to be in the first century AD.

Thus in this code:

  Date date1 = new Date(...);
  Date date2 = format.parse(format.format(date1));

date2 may or may not be the same as date1. Certainly any time information will be stripped out (this is expected), but often date2 will be in the wrong century.

I'm working right now to get the correct localized DateFormat, but ensure that the year portion is four digits, not two.

8 comments:

Craig said...

I think when it comes to standard Java features, Dates and Calendars are the most disappointing.

For example, Calendar.before and Calendar.after take an Object class as a parameter! Want to compare to a Date object? It returns false regardless because a Date object isn't a Calendar object...

There are a lot of examples of why IBM's donated Date/Calendar code is just horrible and inconsistent. Luckily, I believe its being replaced in OpenJDK 7 (correct me if I'm wrong, and I really hope I'm not)

Thiago H de Paula Figueiredo (Thiago HP) said...

You're right: JSR 310: Date and Time API. Extract: "This JSR will draw heavily on experience gained from the Joda-Time project (http://joda-time.sourceforge.net)."

Bill Holloway said...

We wound up writing our own date class because of these problems.

Howard said...

Yep, and the problem with using JODA or your own code is the extra effort of extending Tapestry and Hibernate to know what to do with those new types.

Bill Holloway said...

Absolutely. We then ran off and wrote our own property edit block to handle the new type. We have to maintain that code now. A pain, but we got the field.

Jon Scott Stevens said...

We wrote our own, but this will probably solve your problem or at least get you started.

http://joda-time.sourceforge.net/contrib/hibernate/userguide.html

JODA is *the* way to go.

Jon Scott Stevens said...

By the way, I compared their PersistentDateTime with our version of it and the code is nearly identical so I'd say it is a good solution since our code has been in production for over a year now without any problems.

Jon Scott Stevens said...

Shoot, I take back what I said... the objects aren't marked as Serializable so if you try to deploy it in a cluster you get massive failure. So, take their code, extend the objects with a wrapper and make them Serializable. =)