You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As discussed on the mailing list, the jackson-datatype-jsr310 project needs a new SerializationFeature and two new DeserializationFeatures. First:
SerializationFeature.WRITE_DATE_TIMESTAMPS_AS_NANOSECONDS and DeserializationFeature.READ_DATE_TIMESTAMPS_AS_NANOSECONDS: Unlike Date, Calendar, and Joda, JSR-310 data types have nanosecond resolution. This improved accuracy must not be wasted. However, without a way to turn it on and off, JSR-310 serialization/deserialization could be incompatible with other frameworks or previously-persisted JSON data. These proposed settings would enable nanosecond resolution to be taken advantage of without breaking anything. These new settings should be be ENABLED by default so that the highest resolution is enabled by default (since they only apply to JSR-310 for now). If other frameworks (like Joda) ever supported nanoseconds, these settings could then be used there.
Finally:
DeserializationFeature.ADJUST_DATES_TO_CONTEXT_TIME_ZONE: Right now, any Date, Calendar, Joda, or JSR-310 data types that include time zone information (and are deserialized from strings instead of timestamps) are automatically adjusted upon deserialization to the DeserializationContext's time zone. That time zone is UTC by default, but can be changed by the user (for example, by calling ObjectMapper#setTimeZone()). However, the problem with this is that, sometimes, the time zone information included in the string to be deserialized is useful and the user may need to know this information. Automatically adjusting the time zone of these types without the ability to disable it irrevocably masks this data from the user. The DeserializationFeature.ADJUST_DATES_TO_CONTEXT_TIME_ZONE setting, which would be ENABLED by default (preserving the existing behavior as-is), could be disabled to turn this behavior off. All existing code dealing with date-time deserialization should also be updated to abide by this setting.
The text was updated successfully, but these errors were encountered:
Created #204 and FasterXML/jackson-datatype-joda#16 to track retrofitting to make use of DeserializationFeature.ADJUST_DATES_TO_CONTEXT_TIME_ZONE; marking this as closed.
As discussed on the mailing list, the jackson-datatype-jsr310 project needs a new SerializationFeature and two new DeserializationFeatures. First:
SerializationFeature.WRITE_DATE_TIMESTAMPS_AS_NANOSECONDS
andDeserializationFeature.READ_DATE_TIMESTAMPS_AS_NANOSECONDS
: Unlike Date, Calendar, and Joda, JSR-310 data types have nanosecond resolution. This improved accuracy must not be wasted. However, without a way to turn it on and off, JSR-310 serialization/deserialization could be incompatible with other frameworks or previously-persisted JSON data. These proposed settings would enable nanosecond resolution to be taken advantage of without breaking anything. These new settings should be be ENABLED by default so that the highest resolution is enabled by default (since they only apply to JSR-310 for now). If other frameworks (like Joda) ever supported nanoseconds, these settings could then be used there.Finally:
DeserializationFeature.ADJUST_DATES_TO_CONTEXT_TIME_ZONE
: Right now, any Date, Calendar, Joda, or JSR-310 data types that include time zone information (and are deserialized from strings instead of timestamps) are automatically adjusted upon deserialization to the DeserializationContext's time zone. That time zone is UTC by default, but can be changed by the user (for example, by callingObjectMapper#setTimeZone()
). However, the problem with this is that, sometimes, the time zone information included in the string to be deserialized is useful and the user may need to know this information. Automatically adjusting the time zone of these types without the ability to disable it irrevocably masks this data from the user. TheDeserializationFeature.ADJUST_DATES_TO_CONTEXT_TIME_ZONE
setting, which would be ENABLED by default (preserving the existing behavior as-is), could be disabled to turn this behavior off. All existing code dealing with date-time deserialization should also be updated to abide by this setting.The text was updated successfully, but these errors were encountered: