Add JavaTimeFeature.NORMALIZE_DESERIALIZED_ZONE_ID
to allow disabling ZoneId normalization on deserializationย #281
Description
Change in 2.15 to normalize zone when deserializing to ZonedDateTime causes breakage in some applications because normalized time zone does not match configured Jackson time zone. Would be nice to have ObjectMapper configuration that allows for turning normalization on and off.
Details
There are many places where we're comparing ZonedDateTime fields deserialized from stored JSON strings (format written out: "2023-02-02T20:23:11.057Z"), to ZonedDateTime objects created in code with ZoneId.of("UTC") .
Comparing a ZonedDateTime object created by application code to one deserialized from JSON now no longer works because the zones are not equal. (Zone of the deserialized JSON got normalized to "Z" starting in 2.15 release).
This happens whether relying on Jackson default time zone OR specifically configuring the ObjectMapper / Jackson to use time zone "UTC".
Fixing seems to mean replacing anywhere in code using ZoneId "UTC" with the offset zone Z, but that's a lot of application code to go through.
Notes from comments on issue #267
@indyana If you'd like to see configurability, please file a new issue as RFE, asking for configurability, referencing back to this issue. Then if anyone has time and interest they could work on adding this feature -- it does sound useful.
One practical complication here is just that module does not yet have configurability, so would probably need to add a JavaTimeModule.Feature
enum and a bit of scaffolding. Aside from that should be quite straight-forward.
Originally posted by @cowtowncoder in #267 (comment)