You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
java9+ OffsetDateTimeSerializer/OffsetDateTimeDeserializer miliseconds instead of nano config #161
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
This is probably difference in JDK, regarding either default serialization of the type, or handling of time format strings. As such I think 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:
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.
Reacted by MINSOO, NAM, Peter, Michael Zilske and Cosimo Damiano Prete
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.
Activity
cowtowncoder commentedon Jan 30, 2020
This is probably difference in JDK, regarding either default serialization of the type, or handling of time format strings. As such I think 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 commentedon Jan 30, 2020
Speaking of StackOverflow, would GedMarc's idea work: #71 (comment) (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 commentedon Feb 18, 2020
@kupci Possibly? If anyone wants to do patch for Jackson 2.11 (along with test), would be happy to merge
kupci commentedon Feb 19, 2020
I'll take a look. I've got Java 11 installed, which I think meets the requirements to reproduce the issue:
cowtowncoder commentedon Feb 21, 2020
Our Travis builds check both java 8 and java 11 fwtw (and once 14 becomes available, that; focusing on LTS versions)
plebcity commentedon Dec 24, 2021
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.
cdprete commentedon Oct 8, 2025
Kind of the same here #374
cdprete commentedon Oct 13, 2025
@drej1 would #374 solve the problem for you?