Serialize Instant fields as ISO-8601 strings (#49715)

[pure-zero]

Description

Fixes java.time.Instant fields (and other java.time types handled by Jackson's JavaTimeModule, e.g. LocalDateTime) serializing as a numeric
epoch timestamp instead of an ISO-8601 string when written through the default CosmosItemSerializer (#49715)

Root cause: Utils.createAndInitializeObjectMapper() (com.azure.cosmos.implementation.Utils) registers Jackson's JavaTimeModule but never
disables SerializationFeature.WRITE_DATES_AS_TIMESTAMPS, which defaults to true on a plain ObjectMapper. Since this is the single factory
backing Utils.getSimpleObjectMapper() / Utils.getDocumentObjectMapper(...) — which CosmosItemSerializer.DEFAULT_SERIALIZER uses for every item
read/write on both CosmosContainer and CosmosAsyncContainer — every Instant field was silently written as a number (e.g.
1690019200.123456789) instead of a quoted ISO-8601 string (e.g. "2023-07-22T09:46:40.123456789Z").

Fix: explicitly configure SerializationFeature.WRITE_DATES_AS_TIMESTAMPS = false alongside the JavaTimeModule registration.

Compatibility: this only changes the write format going forward. Jackson's InstantDeserializer recognizes a numeric JSON token as epoch time
independent of this flag, so existing items already stored with epoch-numeric date fields continue to deserialize correctly into Instant — no
data migration needed. It's flagged as a breaking change because any downstream consumer (non-Java SDKs, raw JSON tooling, dashboards) that
was relying on the old numeric wire format will now see a string instead.

All SDK Contribution checklist:

• [] The pull request does not introduce [breaking changes] - This is behaviour changing but non breaking for existing data, happy to discuss this.
• CHANGELOG is updated for new features, bug fixes or other significant changes.
• I have read the contribution guidelines.

General Guidelines and Best Practices

• Title of the pull request is clear and informative.
• [x ] There are a small number of commits, each of which have an informative message. This means that previously merged commits do not appear in the history of the PR. For more information on cleaning up the commits in your PR, see this page.

Testing Guidelines

• Pull request includes test coverage for the included changes.

[github-actions]

Thank you for your contribution @pure-zero! We will review the pull request and get back to you soon.

[Copilot]

Pull request overview

This PR fixes java.time (e.g., Instant, LocalDateTime) JSON serialization in the Cosmos DB Java SDK’s default item serializer by ensuring the shared Jackson ObjectMapper writes ISO-8601 strings instead of numeric epoch timestamps.

Changes:

• Disable SerializationFeature.WRITE_DATES_AS_TIMESTAMPS on the default Cosmos ObjectMapper created by Utils.createAndInitializeObjectMapper(...).
• Add unit tests validating the ObjectMapper configuration and Instant ISO-8601 serialization/round-trip behavior through both Utils and the default CosmosItemSerializer.
• Document the behavior change in the azure-cosmos changelog (as a breaking change).

Reviewed changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated 1 comment.

File	Description
sdk/cosmos/azure-cosmos/src/main/java/com/azure/cosmos/implementation/Utils.java	Configures the shared Jackson ObjectMapper to serialize Java time types as ISO-8601 strings.
sdk/cosmos/azure-cosmos/CHANGELOG.md	Adds a breaking-change entry describing the new default wire format for java.time fields.
sdk/cosmos/azure-cosmos-tests/src/test/java/com/azure/cosmos/implementation/UtilsTest.java	Adds unit coverage ensuring WRITE_DATES_AS_TIMESTAMPS is disabled and Instant serializes as an ISO-8601 JSON string.
sdk/cosmos/azure-cosmos-tests/src/test/java/com/azure/cosmos/CosmosItemSerializerUnitTests.java	Adds unit coverage verifying the default serializer writes Instant as ISO-8601 and can round-trip it.

[pure-zero]

@pure-zero please read the following Contributor License Agreement(CLA). If you agree with the CLA, please reply with the following information.

@microsoft-github-policy-service agree [company="{your company}"]

Options:

• (default - no company specified) I have sole ownership of intellectual property rights to my Submissions and I am not making Submissions in the course of work for my employer.

@microsoft-github-policy-service agree

• (when company given) I am making Submissions in the course of work for my employer (or my employer has intellectual property rights in my Submissions by contract or applicable law). I have permission from my employer to make Submissions and enter into this Agreement on behalf of my employer. By signing below, the defined term “You” includes me and my employer.

@microsoft-github-policy-service agree company="Microsoft"

Contributor License Agreement

@microsoft-github-policy-service agree