Feature request: DeserializationFeature.OPTIONAL_TIME_ZONE

Bắt đầu với InstantDeserializer, thành phần xử lý các giá trị Instant và ZonedDateTime, rồi kiểm tra DeserializationContext#getTimeZone. Xác định DeserializationFeature.OPTIONAL_TIME_ZONE được đề xuất sẽ ảnh hưởng thế nào đến việc phân tích khi thiếu hậu tố, đồng thời giữ nguyên các múi giờ được chỉ định rõ ràng. Hoàn tất nghĩa là cả hai chuỗi ví dụ đều được giải tuần tự thành các giá trị tương đương với múi giờ dự phòng đã cấu hình, còn các đầu vào có múi giờ hiện có không thay đổi.

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.