search

FasterXML / jackson-modules-java8

Set of support modules for Java 8 datatypes (Optionals, date/time) and features (parameter names)
Apache License 2.0
401 stars 117 forks source link

java9+ OffsetDateTimeSerializer/OffsetDateTimeDeserializer miliseconds instead of nano config #161

Open drej1 opened 4 years ago

drej1 commented 4 years ago

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

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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

kupci commented 4 years ago

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 commented 4 years ago

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

plebcity commented 2 years ago

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.