CODEWITHSUNDEEP
javajsonjacksonjodatime
Vysarat
Vysarat

Reputation: 404

Jackson loses time offset from dates when deserializing to JodaTime

I'm trying to serialize and then deserialize a Joda DateTime object using Jackson, but it doesn't deserialize the object fully. It looks like timezone information is lost.

This code:

ObjectMapper mapper = new ObjectMapper();
mapper.registerModule(new JodaModule());
mapper.configure(com.fasterxml.jackson.databind.SerializationFeature.WRITE_DATES_AS_TIMESTAMPS , false);

DateTime dt = DateTime.now();
String j = mapper.writeValueAsString(dt);
DateTime dt2 = mapper.readValue(j, DateTime.class);

System.out.println("json: " + j);
System.out.println("eq? " + (dt.equals(dt2)));
System.out.println("dates:\n" + dt + "\n" + dt2);

outputs this:

json: "2013-10-18T14:10:52.458-07:00"
eq? false
dates:
2013-10-18T14:10:52.458-07:00
2013-10-18T21:10:52.458Z

Is this by design? Is there anything I can do here, short of writing my own serializer/deserializer? I've seen a few questions about this on SO, but none that deal with this aspect specifically.

I'm using Joda 2.1 and Jackson 2.1

Upvotes: 9

Views: 6488

Answers (3)

Kai Moritz
Kai Moritz

Reputation: 621

Jackson must be told to not adjust the time-zone to that of the local context by:

mapper.disable(DeserializationFeature.ADJUST_DATES_TO_CONTEXT_TIME_ZONE);

See this issue on GitHub

Upvotes: 11

Viktor Aseev
Viktor Aseev

Reputation: 698

Yes, this is by design. JodaTime DateTimeSerializer use standard toString() method. According to JodaTime official guide toString() returns - the standard ISO8601 string for the DateTime. Also, standard DateTimeDeserializer always creates UTC datetimes.

To store TimeZone you need to store it separately with same json and use .withZone() method after deserialization or just create serializer and deserializer.

UPDATE

Version 2.2.3 have a bit extended behaviour - DateTimeDeserializer creates DateTime with timeZone taken from DeserializationContext. it may be changed with ObjectMapper.setTimeZone(). Default is TimeZone.getTimeZone("GMT")

Upvotes: 8

Jim Garrison
Jim Garrison

Reputation: 86774

From the Javadoc for AbstractInstant#equals() which is a superclass of DateTime:

Compares this object with the specified object for equality based on the millisecond instant, chronology and time zone. (my emphasis)

Two objects which represent the same instant in time, but are in different time zones (based on time zone id), will be considered to be different. Only two objects with the same DateTimeZone, Chronology and instant are equal.

The two dates you show designate the same instant, but since they have different timezones JodaTime says they're not "equal". I don't see anything wrong with how Jackson is handling them.

Upvotes: 1

Related Questions