Modify Joda DateTime serializing/deserializing to enable including the time-zone

Example implementation of how I'm currently keeping the DateTimeZone in tact with a DateTime during serialization/de-serialization.

Will defer post-1.6 just because this is best integrated when adding new modular registration mechanism.

Right now the deserializing of a DateTime object always set the time zone to UTC. Maybe using default locale to determine timezone would be a better fallback?

Explicitly added timezone information should definitely not be overridden. Question on default timezone to use for cases where no info is passed can probably be solved by giving choice of 'local' or 'UTC' (just need to figure out what would be better default).
I am still hoping to get a reasonable plug-in system, which would allow better integration with Joda lib, for 1.7./

Hmmh. I think that on plus side actual value is correctly handled (i.e. deserialized value is not wrong, wrt universal time; just expressed in different timezone). But wherever specified, should be retained and properly brought back. This can not be done when using pure numeric timestamps, which will need to default to some timezone. We also can not change default serialization to use JSON objects I think; but this should be possible to resolve for String serialization.

At practical level change will be visible so this will need to go in 1.7.0 (and not 1.6.x patch release); plan is to get get 1.7.x (and esp. first snapshots) our relatively soon so this won't necessarily delay fix a lot.

I think this is a good candidate to actually implement as an add-on module; not only can it then be done in backwards-incompatible way, but it can also expand the scope. For example, it would be possible to handle JDK date types using Joda datetime, which is probably more robust way.

For example modules, have a look at:

https://github.com/organizations/FasterXML

of which 'guava' module is most complete at this point.

Module interface is new with 1.7.0, so this feature can be released after 1.7 is out; but can be developed concurrently. And after this, can be developed independently.

Any update on where this sits in terms of priorities? I agree making this be a module makes sense. Is there any formal process for creating an official "FasterXML" module?

FYI that here is a corrected link for previous modules: https://github.com/FasterXML/

Ok: here is it: https://github.com/FasterXML/jackson-datatype-joda.

Please let me know your Github account id so I can give you access?

Hi Tatu,

Thanks for setting this up. In looking at the needs for me team, I see they are more specific than what a generic than what the "joda-time" module should provide, and that to make a more generic implementation would take more time than we currently have. I've put this on my todo list to come back and revisit, but for the time being am going to have to hold. I'd certainly be happy to consult or review any work if someone else leads this charge.

Thanks,
Steve

Ok thanks for update.

I think that realistically work can start along with Jackson 2.0 development, in which all Joda-specific stuff will most likely move out of core Jackson package.

Hi Steve! Not sure if you are following this, but I just moved all Joda handling from 2.0.0 databind into https://github.com/FasterXML/jackson-datatype-joda.
As a result, I will close this entry, and let all new feature requests, changes etc be added for that project. It is very easy to give access, pull merge requests etc, so let us know what is needed.

Closing to re-create necessary issues for Joda module.