Feature request: DeserializationFeature.OPTIONAL_TIME_ZONE

从处理 Instant 和 ZonedDateTime 值的 InstantDeserializer 开始，并检查 DeserializationContext#getTimeZone。确定在缺少后缀时，提议的 DeserializationFeature.OPTIONAL_TIME_ZONE 应如何影响解析，同时保留显式时区。完成的标准是：两个示例字符串都使用配置的回退时区反序列化为等价的值，并且现有的带时区输入保持不变。

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.