Adjust existing Date/Time deserializers to support `DeserializationFeature.ADJUST_DATES_TO_CONTEXT_TIME_ZONE`

[cowtowncoder]

Jackson 2.2 adds DeserializationFeature.ADJUST_DATES_TO_CONTEXT_TIME_ZONE, mostly to support the new (Java 8) Date/Time module.
But it would make sense to retrofit existing handlers for core JDK types, as well as for Joda (will create separate issue there), to also support this feature.

[cowtowncoder]

As per above: this has been implemented for Joda.

Not sure wrt JSR-310 module: looks like it only supports this for InstantDeserializer, not other types.

[cowtowncoder]

Note to self: java.util.Date has no timezone stored, so this would only affect behavior java.util.Calendar. Also: planning to do for 2.9, to try to make 2.8 release very low-impact one wrt backwards compatiblity.

[cowtowncoder]

Hmmh. Ok, so yes, this gets quite complicated I realize -- problem being that TimeZone parsed has to be piped differently: current code uses java.util.Date as parse result and this will not work (since there's no place for timezone basically). Instead, parse methods need to be retrofitted with Calendar and then handle adjustment (or not) appropriately. Fortunately this should be doable with 2.9.

[cowtowncoder]

Ok. Even worse news... it does not look like SimpleDateFormat even gives access to actual timezone information from parsed value. Rather it looks like just timestamp is retained, and essentially needs to be forced into whatever timezone, most likely context timezone.

If timezone information from input is to be retained it seems, then, that Joda / Java 8 datetime has to be used. Or, if someone really wanted to use older Calendar, StdDateFormat would have to be rewritten to do even more of parsing, retain timezone and so for: huge effort for questionable benefit.

So, as of now, I will not pursue this at all. With Calendar, context timezone will always be enabled, regardless of ADJUST_DATES_TO_CONTEXT_TIME_ZONE setting.

[cowtowncoder]

Some more information: PART of timezone information is actually retained, and can be retrieved with:

_dateFormat.getCalendar().get(Calendar.ZONE_OFFSET)

but unfortunately not TimeZone:

_dateFormat.getTimeZone(); // returns originally configured timezone, at least for offsets

Or at least not always: perhaps it is set for named timezones. Worse, there is no way to get timezone info using offsets....