More support for customizing java.time.Instant fields' deserialization/serialization

[a1shadows]

Should there be a SerializationFeature.WRITE_INSTANTS_AS_TIMESTAMPS similar to SerializationFeature.WRITE_DATES_AS_TIMESTAMPS?

Also, should there be support for @JsonFormat(shape - JsonFormat,Shape.NUMBER) on Instant fields?

Let me know your thoughts. I would be glad to work on such a feature

[cowtowncoder]

Ideally we would get to something better than tons of one-off SerializationFeatures/DeserializationFeatures. JSTEP-5 (https://github.com/FasterXML/jackson-future-ideas/wiki/JSTEP-5) is the idea, but I haven't had time to take a lead on that.
So, while DateTimeFeature addition (similar to new-ish EnumFeature and JsonNodeFeature) seems like the way to go, things get bit complicated when trying to revamp everything.

But as to Instant, what all date/time types would be included (of JDK ones, Joda)?
How would compatibility work wrt existing settings?

[a1shadows]

In my view, everything that can be done with the java.util.Date should also be possible on java.time.Instant. This is because as per my general observation, java developers are replacing use of Date with uses of Instant in new applications for most use cases and expect to port all their configurations.

With that said, it looks like @JsonFormat(shape - JsonFormat,Shape.NUMBER) can be used for epoch representation of Instant right now. It is also possible to customize the format in other ways (#4278 (comment)). I missed this initially when starting this discussion.

So, it looks like (https://github.com/FasterXML/jackson-future-ideas/wiki/JSTEP-5) will be the way to go instead of one off type features. Maybe I can help with it. Do you have any specific direction that you would like to go with DateTimeFeature, or it is still in the ideation phase right now?

[cowtowncoder]

DateTimeFeature is more like mechanism to split off related things from Deserialization-/SerializationFeature, not descriptive on its own.
So it's more ideation; requiring someone to think of date/time handling as a whole.
But this has traditionally been a problem area with many chefs, people introducing bit-wise changes.
(exception being Java 8 date/time module that was originally contributed by a single developer, but one who hasn't been active for past couple of years).

It might be worth sending a note on jackson-dev google group, asking for interested parties for this discussion.
(not many devs follow issue tracker).

[a1shadows]

@cowtowncoder I've posted on the google group but for whatever reason, my post is not showing up on the feed. Do i require some special permission to submit a post?

[cowtowncoder]

I had to approve it (the first post from a new poster), should have gone through now.

[tmoschou]

Thought I'ld chime in since I had originally proposed in late 2022 on the jackson-dev google group that Jackson 3 should by default serialize date/times using RFC 3339 profile of the ISO 8601 format here https://groups.google.com/g/jackson-dev/c/BfLjoaCF7fQ/m/x4BYSxTuCAAJ - Seemed to have had broad consensus, and I don't think that has changed for many.

Summarising reasons,

• an industry standard for interchange of dates/times
• broad industry adoption across different languages, frameworks, tooling, organisations and API guideline (e.g. OpenAPI, JSON Schema, Google, Microsoft, etc to name a few)
• human/machine readable, not lossy (nanoseconds resolution, timezone), unambiguous, self describing (local date vs offset date time)
• already the format used by java.time .toString()/.parse() methods
• encourage consistent use of ISO 8601 / RFC 3339 - by having ObjectMapper pre-configured out of the box - many developers will not check or know of the finer config options.

Ideally we would get to something better than tons of one-off SerializationFeatures/DeserializationFeatures

Completely agree with this sentiment - more binary feature toggles are going to be more confusing. Example DeserializationFeature.ADJUST_DATES_TO_CONTEXT_TIME_ZONE the default in Jackson 2 is true, and actually results in data not being round tripped exactly, does not quite adhere to the Principle of Least Surprise.

ObjectMapper mapper = JsonMapper.builder().findAndAddModules().build();
OffsetDateTime odt1 = OffsetDateTime.parse("2020-01-01T00:00:00+10:00");
String json = mapper.writeValueAsString(odt1); // "2020-01-01T00:00:00+10:00"
OffsetDateTime odt2 = mapper.readValue(json, OffsetDateTime.class);
System.out.println(odt2); // 2019-12-31T14:00Z  😮

I can't speak for everyone, but personally, I would be in favour of taking an opinionated configuration approach, possibly promoting core java.time classes (Instant, OffsetDateTime, LocalDate, etc) to jackson-databind (as is java.util.Date currently) and using (only?) ISO/RFC as the serialization format (and not requiring JavaTimeModule and its complex feature set). The simplification might actually be easier to maintain if taking an opinionated (restricted) approach? Not sure how feasible that is though. But Jackson 3 would be a good as any to make such a big change.

Should users wish to customise the formatting and deviate from industry norms, they could register their own module to support complex and unusual formats (or possibly JavaTimeModule if feasible), apply custom deserializers, or pre/post-convert manually in the application layer shifting the responsibility onto the user.

[cowtowncoder]

@tmoschou Thank you for writing up this -- I will need to read it with thought after I come back for my vacation (leaving today, back in 2 weeks). But with quick glance I think I agree with most of what you suggest.

In addition, I think that wrt default setting changes for 3.0 (https://github.com/FasterXML/jackson-future-ideas/wiki/JSTEP-2), an obvious change (along your suggestion) would be one proposed but not yet done:

• Change SerializationFeature.WRITE_DATES_AS_TIMESTAMPS to false.

How exactly it'd play with other settings would be open to discussion: one challenge being to ensure proper layering of settings (global WRITE_DATES_AS_TIMESTAMPS being lowest precedence; with per-type overrides), including possible new DateTimeFeature settings. Although I guess that'd be global so would need to decide how specifically model/implement per-type overrides (there is already JsonFormat approach).