java9+ OffsetDateTimeSerializer/OffsetDateTimeDeserializer miliseconds instead of nano config

[drej1]

Hi, we have set SerializationFeature.WRITE_DATES_AS_TIMESTAMPS to false and in java8 it wrote time in milliseconds precision (java worked this way for a long time).
After migrating to java11 the precision is nanoseconds

• (Java 8- - 2020-01-28T16:31:37.698+01:00)
• (Java 9+ - 2020-01-28T16:31:37.698185+01:00)

This is fine, but unfortunately the services both northbound and southbound of our system can work with milliseconds (3 digits). Would it be possible to create a SerializationFeature to enable java8 behavior meaning serializing only to milliseconds precision? We use a spring boot autoconfiguration where we would like to set this globally for all of our microservices.

Thanks, Ondrej

PS: Maybe until then, could you provide us instructions for the best way to setup this in Spring Boot 2.2.x? Thanks

[cowtowncoder]

This is probably difference in JDK, regarding either default serialization of the type, or handling of time format strings. As such I it is possible Jackson does not have much control over these aspects.

As to Spring Boot, that would be good question for Spring Boot user groups or StackOverflow; although maybe other Jackson users could help as well at:

https://groups.google.com/forum/#!forum/jackson-user

[kupci]

Speaking of StackOverflow, would GedMarc's idea work: https://github.com/FasterXML/jackson-modules-java8/issues/71#issuecomment-528000342 (which references setting the precision in the formatter: https://stackoverflow.com/questions/44373144/java-8-how-to-create-datetimeformatter-with-milli-micro-or-nano-seconds)

[cowtowncoder]

@kupci Possibly? If anyone wants to do patch for Jackson 2.11 (along with test), would be happy to merge

[kupci]

I'll take a look. I've got Java 11 installed, which I think meets the requirements to reproduce the issue:

(Java 9+ - 2020-01-28T16:31:37.698185+01:00)

[cowtowncoder]

Our Travis builds check both java 8 and java 11 fwtw (and once 14 becomes available, that; focusing on LTS versions)

[plebcity]

This issue is present again with the upgrade from java 11 to java 17 as they introduced nanoseconds (9 decimals) to java instants. https://bugs.openjdk.java.net/browse/JDK-8242504

This means that an instant created on a linux machine has 9 decimals of milliseconds but an instant created on MacOS has 6 decimals. Instead of truncating everything manually we would love an option to configure how many decimals are accepted and parsed by the Objectmapper.