Skip to content

Need new SerializationFeature and DeserializationFeatures #203

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
beamerblvd opened this issue Apr 9, 2013 · 2 comments
Closed

Need new SerializationFeature and DeserializationFeatures #203

beamerblvd opened this issue Apr 9, 2013 · 2 comments

Comments

@beamerblvd
Copy link
Member

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.

@cowtowncoder
Copy link
Member

Sounds good; I will add features; and also create a separate entry for follow-up work for DeserializationFeature.ADJUST_DATES_TO_CONTEXT_TIME_ZONE.

@cowtowncoder
Copy link
Member

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants