include the time zone name when serializing DateTimes, not just the offs...

[dbyron0]

...et from UTC

I'm curious what people think of this idea, and whether a new SerializationFeature to enable it makes sense. At the moment, the time zone is getting lost. Yes, the instant in time is the same, but the time zone could be important...for example to present to a user in the same time zone s/he provided it initially.

[cowtowncoder]

@dbyron0 I think it'd be good to discuss this on mailing list (I think only minority of devs actively follow issues.

Deserializer change makes sense of course. I am not sure about timezone vs offset question; it seems like something that should be configurable for Joda module I think. Or, if it is general enough, we could add a new SerializationFeature for databind.

[dbyron0]

Thanks for the comment. Are you suggesting http://xircles.codehaus.org/lists/[email protected] ?

[cowtowncoder]

@dbyron0 Sorry for slow follow-up, but now that Jackson 2.6.0 has:

SerializationFeature.WRITE_DATES_WITH_ZONE_ID

the second part could be done dynamically.

However; I am not so sure that use of milliseconds as timestamp is a commonly used practice.
Wouldn't it make more sense to include formatted date/time with zone id here?

@zkiss @sandermak WDYT?

[cowtowncoder]

After trying to find whether there are any de-facto standard inclusion methods, I think:

1. Could not really find an obvious solution everyone or many were using
2. Use of '/' is probably not safe in general as it is used both as separator for other things (time ranges) and also within ids (of time zones, even).

This does not necessarily mean that slash could not be used where appropriate, but that it is hard to generalize using it.

[zkiss]

@cowtowncoder thanks for bringing this to my attention

@dbyron0 yes, this makes sense, the java 8 module has the capability of doing this and SerializationFeature.WRITE_DATES_WITH_ZONE_ID was introduced for enabling the behaviour. By default modules should not include the timezone name, if this feature is enabled then they should. The format should be the format being used in java 8's ZonedDateTime: <ISO date string>[<zone name>] (e.g: 2015-06-18T21:36:00.0[Europe/London]).

For the discussion which has lead to this decision please read:
https://github.com/FasterXML/jackson-datatype-jsr310/issues/13
FasterXML/jackson-datatype-jsr310#15
FasterXML/jackson-databind#794

[cowtowncoder]

Ah. So '[...]' could be used for including zone id -- good. I think it could also be used with timestamp, if such inclusion is deemed useful.

The only (?) thing then is just to implement inclusion for serialization, handling for deserialization. :)

[dbyron0]

The work I was doing here was now two companies ago, and my motivation has plummeted. Sorry for dropping the ball, but I could use a hand moving this forward.

[cowtowncoder]

@dbyron0 Ok no problem, thank you for sending an update; I just want to try to avoid getting conflicting changes.

[cowtowncoder]

Actually, let me create a new issue for replacement, with more accurate title.

[cowtowncoder]

Note: #66 implemented for 2.6.0(-rc4), should now have parity with JSR-310 module.

[Darkvater]

I am not sure this feature is what people are asking for. The timezone still gets converted to UTC but now there is an additional timezone information for the original timezone.

How does one get the following, because right now it seems impossible.
Input: {"timestamp": "2015-01-01T00:00:00+0800“}
Output: {" timestamp": "2015-01-01T00:00:00+0800“}

Without the flag the output gets converted to UTC, with the flag it still is UTC but with [+0800] appended to the end. Do we still need a custom serializer? When can we expect a simple idempotent serializer/deserialzer for joda datetime?

[cowtowncoder]

@Darkvater as soon as someone contributes a patch.