Feature request: DeserializationFeature.OPTIONAL_TIME_ZONE

Inizia con InstantDeserializer, che gestisce i valori Instant e ZonedDateTime, e ispeziona DeserializationContext#getTimeZone. Determina come il DeserializationFeature.OPTIONAL_TIME_ZONE proposto dovrebbe influire sul parsing quando il suffisso è assente, preservando i fusi orari espliciti. Il lavoro è completato quando entrambe le stringhe di esempio vengono deserializzate in valori equivalenti con il fuso orario di fallback configurato e gli input zoned esistenti rimangono invariati.

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.