Behaviour of custom date format with regards to the ObjectMapper's default time zone

Tested with Jackson 2.8.8 and 2.8.9.

The general rule with the StdDateFormat with regards to the TimeZone is:

     the TimeZone of the ObjectMapper is used if the JSON input does not contain
     any timezone/offset information.

     If the mapper timezone is set to GMT+1, the input 2000-01-01T00:00:00.000
     (no timezone) will produce a date 2000-01-01T00:00:00.000+01:00

This rule remains valid when the @JsonFormat annotation is used on a property unless it forces an explicit timezeone, in which case it takes precedence.

One would expect the same behavior when the StdDateFormat is replaced by a custom DateFormat on the ObjectMapper. In other words, the timezone of the DateFormat should be of no importance since the ObjectMapper’s default is used whenever needed.

However it appears this behaviour is not always respected and depends on whether the mapper has been explicitly configured with a TimeZone or not.

Suppose the following custom date format:

DateFormat df = new SimpleDateFormat("yyyy-MM-dd'X'HH:mm:ss");
df.setTimeZone( TimeZone.getTimeZone("GMT+4") );

Use it on a vanilla ObjectMapper without any further configuration:

ObjectMapper mapper = new ObjectMapper();
mapper.setDateFormat(df);
Date d = mapper.readValue("2000-01-02X04:00:00", Date.class);

This produces a date with GMT+4 although we would expect UTC according to the “rules” described above.

Do a second test and use the same date format on an ObjectMapper whose timezone is explicitly set to UTC. Since UTC is the default, this test should behave as the first…

ObjectMapper mapper = new ObjectMapper();
mapper.setTimeZone(TimeZone.getTimeZone("UTC"));
mapper.setDateFormat(df);
Date d = mapper.readValue("2000-01-02X04:00:00", Date.class);

Now this produces a date in UTC and not GMT+4 anymore… This is compliant with the rules, but unexpected in the light of the first test. Do the test once more with GMT+2 instead go UTC and the date will be in GMT+2…

This case is covered by the DateDeserializationTest#testDateUtil_customDateFormat_withoutTZ() test case submitted in PR https://github.com/FasterXML/jackson-databind/pull/1660.

Could this be related to https://github.com/FasterXML/jackson-databind/blob/2.8/src/main/java/com/fasterxml/jackson/databind/cfg/BaseSettings.java#L245-L249 ?

[Martin-Luft]

I’m not sure if this is the same issue:

Until 2.9: I set the objectMapper.setTimeZone() and the string 2016-10-30T17:00:00 was interpreted with the given time zone and not as UTC.

Since 2.9: The string 2016-10-30T17:00:00 is interpreted as UTC (ignoring my set time zone) which breaks my application logic.

[cowtowncoder]

@Martin-Wegner it definitely sounds like #1657, which may have made it in 2.9.0.pr4 (not 100% sure, fix is quite close to release time), but is definitely in master.