DateTime serialization result is not same as Java 8 ZonedDateTime

[chanjarster]

Version: 2.8.8

Below is the test code:

    LocalDateTime localDateTime = new LocalDateTime(2017, 1, 1, 1, 1, 1);

    ZonedDateTime java8ZonedDateTime = ZonedDateTime.ofInstant(localDateTime.toDate().toInstant(), ZoneId.of("Asia/Shanghai"));
    DateTime jodaDateTime = localDateTime.toDateTime(DateTimeZone.forID("Asia/Shanghai"));

    ObjectMapper objectMapper = new ObjectMapper();
    objectMapper.registerModule(new JodaModule());
    objectMapper.registerModule(new JavaTimeModule());
    objectMapper.disable(SerializationFeature.WRITE_DATES_AS_TIMESTAMPS);

    System.out.println(objectMapper.writeValueAsString(java8ZonedDateTime));
    System.out.println(objectMapper.writeValueAsString(jodaDateTime));

ZonedDateTime result is "2017-01-01T01:01:01+08:00"
while DateTime result is "2016-12-31T17:01:01.000Z", which is convert to UTC timezone.

[cowtowncoder]

So would the expectation here to use and include original timezone offset?
(just want to make sure I don't misunderstand).
I understand preference for uniform output for similar date/time type.

[chanjarster]

@cowtowncoder Yes, I think ZonedDateTime output makes sense, so I prefer output including timezone offset

[cowtowncoder]

Still not 100% what to do here for 2.9. I agree that ideally outputs should match, and further that without explicit configuration, default should be to use existing timezone in values that have it.
But... change would be behavioral change that is better made for 3.0.

[alvinlee001]

Is this solved?

[Flomix]

Bump please solve this :-)

What I don't understand is why there is no configuration for that.
For Deserialisation there is DeserializationFeature.ADJUST_DATES_TO_CONTEXT_TIME_ZONE to enable/disable that normalisation...
why isn't there a SerializationFeature.ADJUST_DATES_TO_CONTEXT_TIME_ZONE? That would solve the whole "downwards compatibility" debate keeping this bug from being fixed for years now.

By the way this bug is a breaker for me too, I need to keep timezones with different values, which work with Java8 but not with Joda.

The whole problem seems to be related to a wrong implementation of SerializationFeature.WRITE_DATES_WITH_ZONE_ID, with this flag enabled the timezone is kept correctly.

[islanderman]

I think the problem happens with SerializerProvider and its use of JacksonJodaDateFormat, which considers Feature and @JsonFormat, but it does not consider actual TimeZone inside DateTime for JacksonJodaDateFormat, as the value is not used till serialize time.

So basically we need to have a default JacksonJodaDateFormat, and this can be ignored whenever DateTime has TimeZone and there's no explicit configuration (therefore default) per @cowtowncoder's comment. But this is a huge change and might break other cases.

---

Here's a POJO example that outputs correct TimeZone.

class Foo {
		@JsonFormat(timezone = ZONE_ID)
		DateTime dateTime;
	}

[Flomix]

that is exactly why I suggested a new SerializationFeature for this, so other cases would not be broken but developers, who need the un-destroyed timezone information, can use joda again.
Such a change would be much smaller and wouldn't need to wait for a 3.0 release. Such a bug shouldn't be open for 2 years.

Plus it would be more consistent, to have corresponding switches for serialization and deserialization.

If I'm not mistaken the problem was introduced with SerializationFeature.WRITE_DATES_WITH_ZONE_ID in the first place, and the timezone information was kept intact correctly before that? That was a breaking change back then as well, wasn't it?

[cowtowncoder]

@Flomix What I really love about users is the deep sense of entitlement for fixes, just by demanding that someone else should go fix things because they say so.

Especially this comment:

"Such a bug shouldn't be open for 2 years."

makes me very, very uninterested in working with you at all.