New project wicket-datetime (using the force)

Those of you following the developer list may already have noticed it, but this weekend I added a new core project to our repository: wicket-datetime.The motivation behind this project is the fact that dealing with the normal date API in the JDK finally drove me insane, and that for the project I’m working on we built a couple of components that depend on a much nicer date API: joda-time.Joda-time is a fantastic example of object oriented craftmanship. I find it’s API elegant and intuitive, and – very important – everything just works like you would expect it to work. That includes working with time zones, which is something I recently had to deal with.Consider this case:We have a system that logs the timestamp when entries of a certain entity were added.Now say, I’m working in Seattle, and the server is in Amsterdam. Amsterdam is nine hours ahead of Seattle. If I would be adding an entry on monday evening the 5th of february, the entry would be saved as being added on tuesday the 6th, as that is the date the server would be working in. Hence, even though it is still monday evening for me, my entry would show up in the list as being added on tuesday morning!The right thing to do here is to take the server date as the reference point, and when communicating with users (displaying and taking input), apply the time zone difference. So, in the above example, the server would store tuesday morning as the date that the entry was saved but it would show up in my browser in Seattle as monday evening.There are multiple strategies you can follow of course, like saving dates including time zone information (probably the safest route to follow), providing the client with time zone information and other variants. However, applying the time zone difference like I sketched above seemed like a generic enough solution to me to justify abstracting a few classes.The wicket-datetime project provides a Converter that takes the client’s time zone into account, and it also provides a date text field that works with this converter. Use that converter for your components, and the time zone difference will be applied for you automatically.The project also provides a new calendar/ date picker component, this time based on the Yahoo User Interface library (YUI) calendar widget. The DatePicker we had before was badly written (sorry for that, I hope I did a better job at this one) as it focussed too much on being ‘easily’ configurable. And the fact that it was based on a javascript widget that had quite a few bugs but wasn’t maintained anymore didn’t really help us feel great about the component either. There is a datepicker in the Dojo integration project, and there might be a fresh one (or two, who knows) put in the wicket-extensions project when someone (Al/ Igor/ Matej?) is up to it. But this date picker is well integrated with the other components in the project and relies of joda-time for it’s functioning (though if there is enough intrest that might be factored out).Finally, two more components that the wicket-datetime project provides at this stage are DateField and DateTimeField. The latter is a nice combination of a date text field, date picker, a field for hours and a field for minutes and a AM/PM selection.I plan to work on this component a bit too, so that it depends on the client’s locale whether a 24 hour system or a 12 hour system with AM/ PM is used.I hope people will start playing with the project soon, and I’m eagerly waiting for suggestions and patches and stuff!