ZonedDateTime serialization fails on milliseconds

[fmunch]

The trailing zeros are stripped:

ZonedDateTime date = ZonedDateTime.of(2018, 4, 16, 19, 37, 23, 10_000_000, ZoneId.of("UTC"));

ObjectMapper objectMapper = new ObjectMapper();
objectMapper.registerModule(new JavaTimeModule());
objectMapper.disable(SerializationFeature.WRITE_DATES_AS_TIMESTAMPS);

System.out.println(objectMapper.writeValueAsString(date));
System.out.println(objectMapper.writeValueAsString(GregorianCalendar.from(date)));

Output:

"2018-04-16T19:37:23.01Z"
"2018-04-16T19:37:23.010+0000"

The first serialization should be "2018-04-16T19:37:23.010Z".

Tested with jackson-datatype-jsr310 2.9.6.

[cowtowncoder]

I am not sure I understand why this would be considered a failure -- value is still the same regardless of trailing zeroes isn't it? ISO-8601 allows variable number of digits for fractional seconds I think.

I think Java 8 default formatters will trim out trailing zeroes in some cases, for better or worse, and I think that is what is happening here.

[fmunch]

I think so too, W3C's format allows 1+ digit. But apparently some parsers have trouble dealing with it.

Anyway, this is not an issue in Jackson. Sorry for the inconvenience.

[marian-soltys]

FYI:
Stumbled on this issue today, for example jackson emits value: "2019-01-14T14:21:36.8Z" (fraction zeros truncated).
Which i'm handling manualy with java8 api:
String testDate = "2019-01-14T14:21:36.8Z"; OffsetDateTime odt = OffsetDateTime.parse(testDate, DateTimeFormatter.ofPattern("uuuu-MM-dd'T'HH:mm:ss.SSSX"));

Error:
Exception in thread "main" java.time.format.DateTimeParseException: Text '2019-01-14T14:21:36.8Z' could not be parsed at index 20 at java.time.format.DateTimeFormatter.parseResolved0(DateTimeFormatter.java:1949) at java.time.format.DateTimeFormatter.parse(DateTimeFormatter.java:1851) at java.time.OffsetDateTime.parse(OffsetDateTime.java:402)

[kupci]

This looks like the same as issue #76, so might need additional documentation around this at the least.

[beamerblvd]

Yes, this issue is essentially identical to #76. Closing as a duplicate.