Missing milliseconds, when parsing Java 8 date-time, if they are zeros

Issue explained here: https://stackoverflow.com/questions/47502158/force-milliseconds-when-serializing-instant-to-iso8601-using-jackson

Version: 2.9.5

How to reproduce: Project where I use Spring Boot 2.0.0.M6, Spring Framework 5.0.1.RELEASE and Jackson 2.9.5

Test 1: Serialize Instant with milliseconds set to 000:

• Initialize Instant field using Instant.parse("2017-09-14T04:28:48.000Z")
• Serialize it using Jackson
• Output will be "2017-09-14T04:28:48Z"

Test 2: Serialize Instant with milliseconds set to some non-000 value:

• Initialize Instant field using Instant.parse("2017-09-14T04:28:48.100Z")
• Serialize it using Jackson
• Output will be "2017-09-14T04:28:48.100Z"

Questions:

• Is that behavior by design?
• Is there anything I can do to force serialization of 000?

[mwmahlberg]

@beamerblvd I disagree. The ObjectMapper, when explicitly asked to serialize with nanosecond precision, should not trim millis.

[beamerblvd]

Finally circling back to some old issues. Here’s my take on this: The ISO standard in question does not require any particular number of fractional-second digits, and ISO-compliant parsers should be able to handle both the presence and absence of fractional-second digits. Given this, it’s logical to conclude that encoders should not need to export a fixed number of fractional-second digits, because parsers should behave. However, that’s a naive position when you dig a little. Not all parsers are well-behaved. In fact, most aren’t. How many Jackson bugs have we fixed here? A lot.

So … I believe the current behavior is the correct default and should be left as the default in all future versions, but I also believe there should be an option to specify a fixed number of fractional-second digits, in order to accommodate those systems that have issues when there are no fractional-second digits.