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.
I think when it comes to standard Java features, Dates and Calendars are the most disappointing.
ReplyDeleteFor 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)
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)."
ReplyDeleteWe wound up writing our own date class because of these problems.
ReplyDeleteYep, 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.
ReplyDeleteAbsolutely. 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.
ReplyDeleteWe wrote our own, but this will probably solve your problem or at least get you started.
ReplyDeletehttp://joda-time.sourceforge.net/contrib/hibernate/userguide.html
JODA is *the* way to go.
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.
ReplyDeleteShoot, 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. =)
ReplyDelete