Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

DateTime serialization result is not same as Java 8 ZonedDateTime #92

Open
chanjarster opened this issue Jul 19, 2017 · 8 comments
Open
Labels

Comments

@chanjarster
Copy link
Contributor

chanjarster commented Jul 19, 2017

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.

@chanjarster chanjarster changed the title DateTime serialize result not same with Java 8 ZonedDateTime DateTime serialization result is not same as Java 8 ZonedDateTime Jul 19, 2017
@cowtowncoder
Copy link
Member

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
Copy link
Contributor Author

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

@cowtowncoder
Copy link
Member

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.

@cowtowncoder cowtowncoder added 3.x and removed 2.9 labels Jul 30, 2017
@alvinlee001
Copy link

Is this solved?

@Flomix
Copy link

Flomix commented Mar 27, 2019

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
Copy link

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
Copy link

Flomix commented Apr 28, 2019

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
Copy link
Member

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

5 participants