Feature request: DeserializationFeature.OPTIONAL_TIME_ZONE

[volkertb]

Hi,

In our project we need to accept ISO8601 date/time strings with optional time zones, where a specific time zone is to be assumed when the time zone is omitted from the string. In our specific case, the assumed time zone would be UTC, regardless of the system's current time zone.

So both of these strings would be deserialized to the same ZonedDateTime object:

• 2018-05-22T10:29:56Z
• 2018-05-22T10:29:56

Unfortunately, the latter cannot be deserialized to a ZonedDateTime (or an Instant for that matter), due to missing (and thus ambiguous) time zone information in the input string. Doing so would result in the following error:

java.lang.IllegalArgumentException: Cannot deserialize value of type `java.time.ZonedDateTime` from String "2018-05-22T10:29:56": Text '2018-05-22T10:29:56' could not be parsed at index 19

However, the specification that we are implementing in our project clearly states that the time zone of the string is supposed to be optional and if omitted, should be assumed to be UTC.

Currently, there is no way for us to tell Jackson to handle the input that way. And deserializing to LocalDateTime instead of ZonedDateTime would not be acceptable either, since that way, any explicitly specified time zone information would be ignored on deserialization.

What would really help here is a specific deserialization feature, named something like DeserializationFeature.OPTIONAL_TIME_ZONE. If enabled, the InstantDeserializer (used for deserializing to both Instant values and ZonedDateTime values) would then treat the time zone suffix (regardless of the notation, whether "Z", "+2:00" or whatever) as optional and assume the value of DeserializationContext#getTimeZone as the time zone when parsing temporal date/time input.

Perhaps there is an obvious existing way to solve this problem, but so far, I was unable to find it. If so, please let me know.

If not, could this proposed DeserializationFeature perhaps be implemented? Thank you kindly for considering this.

[volkertb]

By the way, I think I have located the part of the code that would have to be modified to handle this feature. I believe it would require a change in the method com.fasterxml.jackson.datatype.jsr310.deser.InstantDeserializer#deserialize, since this same deserializer is apparently used for deserializing both Instant and ZonedDateTime values.

[cowtowncoder]

Hmmh. I can see why such handling may be needed, but I am not sure it should be generic DeserializationFeature, for couple of reasons; biggest being that expectation would then be that timezones would truly be optional on all kinds of date/time types. And it is unlikely this would be practical undertaking (due to sheer size).

I think what would probably be better would be ability to customize this module, to allow overriding of deserializer for ZonedDateTime, and modifying deserializer used for that to allow such optional behavior. Configuration would be bit more complicated, but it would achieve the goal and would have limited possibility of regression.

I am not sure exactly how above could and should be achieved, due to relative complexity of InstantDeserializer initialization. But I hope that could serve as starting point.