Add new SerializationFeature, WRITE_DATES_WITH_ZONE_ID to be used by Date/Time modules

[cowtowncoder]

note: cleaved off of FasterXML/jackson-datatype-jsr310#15 -- check out that discussion more complete view.

There are conflicting goals regarding serialization of timezone id information. For example:

• ISO-8601 does not define or support use of timezone ids but only timezone offsets. As such, round-tripping of timezone-aware date/time values will lose timezone identity, even if offset itself is retained
• Some date/time packages do support inclusion and use of timezone ids, above and beyond ISO-8601 notations. But use of such serializations may limit interoperability.

Introduction of this SerializationFeature would allow explicitly choosing between two options, as the global default.

Note: we may also need per-property overrides. But let's tackled that if and when necessary.

[tommack]

Does this feature prescribe a particular format (e.g. https://docs.oracle.com/javase/8/docs/api/java/time/format/DateTimeFormatter.html#ISO_ZONED_DATE_TIME)?

[cowtowncoder]

@tommack if there is consensus on appropriate default format to use, it could and should.

[zkiss]

I'd definitely go with a standardized format, and I'd pick java 8's DateTimeFormatter#ISO_ZONED_DATE_TIME.

[cowtowncoder]

@zkiss Sounds good to me then. I will include this note in javadocs.

One question regarding support: while this is easy to support for JSR-310 module (I assume), and Joda as well I hope, is this something that can easily be supported for basic java.util.Date/Calendar?

[zkiss]

@cowtowncoder That's a good question. Haven't looked into this, but in theory it is possible that even joda ans jsr310 have differences in time zone identifiers. Typos or different namings are possible (although I'd assume with a low chance). Regarding the old java date API a quick search suggests to me it also supports standardized time zone names.

Because of this, I'd first assume there are no differences, maybe check some of them manually, then deal with bugs later as needed.

[cowtowncoder]

@zkiss Fair enough. We can assume it is fair to expect this format -- while it is not the safest choice (might prove to be wrong), there isn't much value in saying "what this really means depends entirely on module".

[tommack]

If both WRITE_DATES_WITH_ZONE_ID and WRITE_DATES_AS_TIMESTAMPS are true, is WRITE_DATES_WITH_ZONE_ID ignored?

[cowtowncoder]

@tommack Yes. WRITE_DATES_WITH_ZONE_ID is only relevant when serialization format is textual. Another way to indicate serialize-as-timestamp is to use @JsonFormat(shape=NUMBER) (vs shape=STRING).

[cowtowncoder]

Feature itself added; use is up to modules: jsr-310 module uses this, but Joda not yet.

[zkiss]

@cowtowncoder AFAIK jsr310 still does not use the feature (I've just checked branch master to make sure). In order to use it serializers (and maybe deserializers as well) should be modified.

[cowtowncoder]

Oh. So the merge was only for separating different modules without functional difference yet?

[zkiss]

JSR310Module and JavaTimeModule behave differently by registering a different class for ZonedDateTime serialization - short term solution.

Long term solution is still to be implemented, by modifying the serializer registered by JavaTimeModule to use this Feature.

[cowtowncoder]

@zkiss ah ok. I will actually reopen this then as a reminder, although separate issues are needed for modules.

[cowtowncoder]

Implemented for Joda module for 2.6.0, closing.