Jackson JSON Processor
  1. Jackson JSON Processor
  2. JACKSON-279

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

    Details

    • Type: Improvement Improvement
    • Status: Closed Closed
    • Priority: Major Major
    • Resolution: Incomplete
    • Affects Version/s: 1.5.1
    • Fix Version/s: None
    • Component/s: JsonParser, Serializer
    • Labels:
      None
    • Number of attachments :
      2

      Description

      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?

      Tatu's response:
      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...]

      1. JsonUtils.java
        5 kB
        Steve Loeppky
      2. JsonUtilsTest.java
        1 kB
        Steve Loeppky

        Activity

        Hide
        Steve Loeppky added a comment -

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

        Show
        Steve Loeppky added a comment - Example implementation of how I'm currently keeping the DateTimeZone in tact with a DateTime during serialization/de-serialization.
        Hide
        Tatu Saloranta added a comment -

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

        Show
        Tatu Saloranta added a comment - Will defer post-1.6 just because this is best integrated when adding new modular registration mechanism.
        Hide
        Geir H. Pettersen added a comment - - edited

        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?

        Show
        Geir H. Pettersen added a comment - - edited 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?
        Hide
        Tatu Saloranta added a comment -

        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./

        Show
        Tatu Saloranta added a comment - 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./
        Hide
        Tatu Saloranta added a comment -

        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.

        Show
        Tatu Saloranta added a comment - 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.
        Hide
        Tatu Saloranta added a comment -

        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.

        Show
        Tatu Saloranta added a comment - 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.
        Hide
        Steve Loeppky added a comment -

        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/

        Show
        Steve Loeppky added a comment - 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/
        Hide
        Tatu Saloranta added a comment -

        I am not actively working on this, and have hoped for possible contributors.
        So if you might have time to help, I can easily create skeletal project and module, and give access?
        There is no format process at this point (not much need yet), so I can just go ahead and create it...

        Show
        Tatu Saloranta added a comment - I am not actively working on this, and have hoped for possible contributors. So if you might have time to help, I can easily create skeletal project and module, and give access? There is no format process at this point (not much need yet), so I can just go ahead and create it...
        Hide
        Tatu Saloranta added a comment -

        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?

        Show
        Tatu Saloranta added a comment - 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?
        Hide
        Steve Loeppky added a comment -

        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

        Show
        Steve Loeppky added a comment - 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
        Hide
        Tatu Saloranta added a comment -

        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.

        Show
        Tatu Saloranta added a comment - 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.
        Hide
        Tatu Saloranta added a comment -

        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.

        Show
        Tatu Saloranta added a comment - 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.
        Hide
        Tatu Saloranta added a comment -

        Closing to re-create necessary issues for Joda module.

        Show
        Tatu Saloranta added a comment - Closing to re-create necessary issues for Joda module.

          People

          • Assignee:
            Tatu Saloranta
            Reporter:
            Steve Loeppky
          • Votes:
            1 Vote for this issue
            Watchers:
            3 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: