Original email question:
It's great to see Jackson have out-of-the-box support for key Joda entities like DateTime. The only issue I see though with the current approach is that all info about the timezone is dropped. I see the serializer for Java's Calendar does the same thing. Is there a reason dropping the timezone was intentionally done? I see there's a feature for writing a DateTime as a string instead of as long for millis. But on the deserializing end, the timezone is specified as UTC (JodaDeserializers line 82). Can the TimeZone code be included on the serialized output so that it can be properly applied when deserializing?
I think my initial main concern was just that the local time zone would never be accidentally used (since that is often the default). As such UTC is defined in many places. But if an explicit timezone is provided, it would be nice to retain it. Intention is definitely not to forcibly remove it; some conversion could cause it to be dropped (like using long to represent timestamp etc).
[Possible solution coming...]