`WRITE_DATE_TIMESTAMPS_AS_NANOSECONDS`/`READ_DATE_TIMESTAMPS_AS_NANOSECONDS` only work on numeric timestamps

[cdprete]

Hello.

I'm using Spring Boot 3.5.6 with Java 25 and I need a way to have Jackson to serialize/deserialize date-time values up to milliseconds precision and not higher (nanoseconds, actually).

I tried setting write-date-timestamps-as-nanoseconds and read-date-timestamps-as-nanoseconds to false, but it looks like they're simply ignored if I don't have write-dates-as-timestamps to true.
Indeed, I would like to have my JSON contain a date-time in the ISO standard format and not as a long value, but I wasn't able to find anything in the documentation for this.
I wonder why such a feature is provided only for numeric timestamps. It should work for both IMHO.

Below a small test case to reproduce the issue:

@SpringBootTest(
        webEnvironment = MOCK,
        properties = {
                //"spring.jackson.serialization.write-dates-as-timestamps=true",
                "spring.jackson.serialization.write-date-timestamps-as-nanoseconds=false",
                "spring.jackson.deserialization.read-date-timestamps-as-nanoseconds=false"
        }
)
public class ObjectMapperTest {
    @Autowired
    private ObjectMapper objectMapper;

    @Test
    public void shouldHandleDateTimeUpToMillis() throws JsonProcessingException {
        // given
        Instant instant = Instant.now().with(NANO_OF_SECOND, 1);
        assertThat(instant.getNano()).isNotZero();

        // when
        String serialized = objectMapper.writeValueAsString(instant);

        // then
        Instant deserialized = objectMapper.readValue(serialized, Instant.class);
        assertThat(deserialized).isEqualTo(instant.truncatedTo(MILLIS));
    }
}

[JooHyukKim]

Hmmm, first of all, it would be good to have Jackson-only configuration & reproduction, so we know exactly how the Mapper is configured and work.

Anyway, if there isn't a feature to serialize-deserialize the way you want, you can always create a custom serializer, deserializer.

[cdprete]

Of course I could create a custom serializer and deserializer for this, but it would be just a workaround and it won't really solve the fact that the library is inconsistent in what it provides given that it provides this feature already for numerical timestamps.

Here I'm asking to fix such inconsistency.

Hmmm, first of all, it would be good to have Jackson-only configuration & reproduction, so we know exactly how the Mapper is configured and work.

I'll try to provide one as soon as I've time.

[JooHyukKim]

As you already seen comment in similar issue, you know inconsistency is made in JDK and I think what you are asking here is feature to mitigate that inconsistency?

Yes, with no Spring, just Jackson configuration and JUnit test.
Couple of comments on the test code describing what should pass and not will be great!

[cdprete]

No, I'm asking to get the inconsistency in the library to be fixed.

I'm not asking for interoperability between Java < 9 and the rest here, but to have the same feature flags available already for numerical timestamps also for non-numerical ones.

In the test above, if I uncomment the feature flag to write date-times as numerical timestamps (overriding therefore the settings from Spring Boot which uses non-numerical timestamps), the test will pass.
On the other end, if I keep that line commented out, the test fails.

This shows that the library is inconsistent, since the JDK is the same for both the executions.

[JooHyukKim]

This shows that the library is inconsistent, since the JDK is the same for both the executions.

Oh okay then let's first have reproduction without Spring, so we can pin-down the inconsistency being created here.

Kind of the same here #374

I thought you meant "same" here :-0

[cdprete]

This shows that the library is inconsistent, since the JDK is the same for both the executions.

Oh okay then let's first have reproduction without Spring, so we can pin-down the inconsistency being created here.

Kind of the same here #374

I thought you meant "same" here :-0

"Kind of" the same, because if those feature flags would be consistent they would not have the issue either. They could then, as well, disable the nanoseconds resolution and be fine (I think).

[cdprete]

@JooHyukKim here a test with just ObjectMapper:

public class ObjectMapperTest {
    @Test
    public void shouldAllowMillisPrecision() throws JsonProcessingException {
        // given
        Instant instant = Instant.now().with(NANO_OF_SECOND, 1);
        Instant expected = instant.truncatedTo(MILLIS);

        ObjectMapper om = new ObjectMapper();
        om.registerModule(new JavaTimeModule());
        om.disable(SerializationFeature.WRITE_DATES_AS_TIMESTAMPS); // Commenting this out makes the test pass
        om.disable(SerializationFeature.WRITE_DATE_TIMESTAMPS_AS_NANOSECONDS);
        om.disable(DeserializationFeature.READ_DATE_TIMESTAMPS_AS_NANOSECONDS);

        // when
        String serialized = om.writeValueAsString(instant);
        Instant deserialized = om.readValue(serialized, Instant.class);

        // then
        assertThat(deserialized).isEqualTo(expected);
    }
}

[cowtowncoder]

Jackson version? (specifically, 2.20.0 or 3.0.0 ?)

[cdprete]

Jackson version? (specifically, 2.20.0 or 3.0.0 ?)

It's 2.19.2 in the BoM imported by Spring Boot 3.5.6.

[JooHyukKim]

Commenting out or not, is too naive for a hint.

So when
SerializationFeature.WRITE_DATES_AS_TIMESTAMPS is....

• enabled, the instant is serialized as "1760200459000", and this would pass, because affected by READ/WRITE_DATE_TIMESTAMPS_AS_NANOSECONDS features
• disabled, the instant is serialized as "2025-10-11T16:27:19.000000001Z", would fail the test, because you are testing the deserialized with MANUALLY trunclated textual timestamp.

@cdprete I don't think there could be any symmetry between the two

• Correctly desrialized with nanosecond 1, from "2025-10-11T16:27:19.000000001Z", and
• MANUALLY TRUNCATED nanosecond "2025-10-11T16:27:19Z"

If you test assertEquals(deserialized, instant); not with expected, would pass already.

[cdprete]

Commenting out or not, is too naive for a hint.

So when SerializationFeature.WRITE_DATES_AS_TIMESTAMPS is....

• enabled, the instant is serialized as "1760200459000", and this would pass, because affected by READ/WRITE_DATE_TIMESTAMPS_AS_NANOSECONDS features
• disabled, the instant is serialized as "2025-10-11T16:27:19.000000001Z", would fail the test, because you are testing the deserialized with MANUALLY trunclated textual timestamp.

@cdprete I don't think there could be any symmetry between the two

• Correctly desrialized with nanosecond 1, from "2025-10-11T16:27:19.000000001Z", and
• MANUALLY TRUNCATED nanosecond "2025-10-11T16:27:19Z"

If you test assertEquals(deserialized, instant); not with expected, would pass already.

Commenting out or not, is too naive for a hint.

That's all what takes to show the inconsistency.

With READ/WRITE_DATE_TIMESTAMPS_AS_NANOSECONDS you have the library being able to handle a FULL Instant and reading/writing it then up to the milliseconds. But only for WRITE_DATES_AS_TIMESTAMPS date-times.

disabled, the instant is serialized as "2025-10-11T16:27:19.000000001Z", would fail the test, because you are testing the deserialized with MANUALLY trunclated textual timestamp.

That's what I'm saying since the beginning and the test wanted to prove it.
Those flags are simply being ignored for NON-NUMERICAL timestamps.
Therefore, the library is inconsistent.

I see 2 ways to fix this:

• you offer a new pair of flags for non-numerical timestamps which carry on the same behavior of the existing ones
• you still offer a new pair of flags (or reuse the existing ones) which would be applied to both the representations and deprecate the existing ones.

[cowtowncoder]

Quick note: as Javadocs for SerializationFeature say:

    /**
     * Feature that controls whether numeric timestamp values are
     * to be written using nanosecond timestamps (enabled) or not (disabled);
     ...
     */
    WRITE_DATE_TIMESTAMPS_AS_NANOSECONDS(true),

(and same for matching DeserializationFeature) this only applies to numeric timestamps and not to textual ISO-8601 serialization.

So behavior is as documented -- and feature name itself suggests it applies to TIMESTAMPS -- same for Spring properties.

So what you are asking, I think, is to allow something similar for ISO-8601 serializations.

This would be a new feature, not a bug (just wrt issue title)
But given that Jackson 3.0.0 was just released and the plan is to move 2.x more to bug-fix mode, I think such new functionality would need to be for Jackson 3.x.
If so, we could, perhaps consider new DateTimeFeature flags.

Although I am not quite if simple flags are the way to do it.

Also: wouldn't @JsonFormat configuration allow specifying desired DateTimeFormat for only including milliseconds in serialization?
Maybe solution is as simple as that.

[cowtowncoder]

Fwtw, it is possible to both use annotation

class Value {
  @JsonFormat(pattern = "yyyy-MM-dd'X'HH:mm")
  public LocalDateTime dt;
}

and set defaults for various types:

        ObjectMapper m = mapperBuilder().withConfigOverride(LocalDateTime.class,
                cfg -> cfg.setFormat(JsonFormat.Value.forPattern("yyyy-MM-dd'X'HH:mm")))
            .build();

(obv pattern here wouldn't be one to use, and type would be something other than LDT -- I just picked examples from module unit tests).

Hope this helps!