I'm not a member of the list, but I would like to share a few thoughts about the AXIS behavior when it comes to (default) date serialization.
java.util.Date's are converted to GMT, then the hours, minutes, and seconds are truncated. First of all, I wonder _why_ someone thought it wise to lose the hour, minute, and second information. According to the link in the Javadoc, it looks to me this information would get preserved. The java.util.Calendar class information is converted (IMHO) correctly. When I send a date, such as Sunday 5:31PM PST, it comes back to me as Sunday 17:00 PST, which isn't midnight in my Locale (PST), but midnight GMT. Which I thought was mysterious for my dates to do. For the application I'm working on, I don't care about Europe. (At least for now.) As a work-around, users have to write their own serializers and stuff to fix this (annoying?) problem. This is not easy to do. Bean serialization should do the expected thing. This would be like dropping the decimal point for floating point values without mentioning things. I would like to petition (suggest) to have the serialization behavior changed to something that would make more sense. 1) By default, serialize the time of day parts as well. Midnight on some date (could magically become today or tomorrow) in the UK is irrelevant to many users. 2) Be capable of handling either the shortened date or the longer date. I'd have to read the spec on the short date, but it seems to me if you don't know the timezone (it's a date minus the 'Z'), it is indeterminate which time you're talking about, but probably would be best to decode into the computer's default timezone. Good luck in getting a stable release out the door. Please CC replies to me, if you care to.
