fix: serialise OffsetDateTime as RFC 3339

[dudanogueira]

Motivation

OffsetDateTime.toString() drops the seconds when the second and the nanosecond are both zero, so 2024-03-01T00:00:00Z goes on the wire as 2024-03-01T00:00Z. RFC 3339's partial-time requires hour ":" minute ":" second, and Weaviate rejects the short form:

invalid date property 'when' on class 'X': requires a string with a RFC3339 formatted date,
but the given value is '2024-03-01T00:00Z'

Every timestamp on an exact minute boundary is affected — which is most timestamps written by hand — and it breaks writes and filters alike. toString() is a display format, not a wire format.

Approach

DateUtil already owned the read side (fromISO8601) but had no write-side counterpart, which is exactly why the same toString() call got copy-pasted into every marshalling site. It now has toRFC3339(), and all six sites call it.

The formatter is built with DateTimeFormatterBuilder rather than ofPattern("yyyy-MM-dd'T'HH:mm:ssXXX"): the pattern form would fix the reported bug while silently truncating sub-second precision that works today. appendFraction(NANO_OF_SECOND, 0, 9, true) keeps the fraction variable-width, so it is neither invented for whole seconds nor truncated for nanos.

Scope: six call sites, not three

The issue named three. The list and array variants have the same bug:

Site	Path	In the report
Filter.DateOperand.appendTo	gRPC search	yes
Filter.DateArrayOperand.formatted	containsAny/containsNone	no
InsertManyRequest scalar	gRPC batch	yes
InsertManyRequest List<OffsetDateTime>	gRPC batch	no
InsertManyRequest OffsetDateTime[]	gRPC batch	no
DateUtil Gson TypeAdapter	REST	yes

Aggregate filters, boost filters and deleteMany all funnel through Filter, so they are fixed without separate changes. Filter.DateOperand.toString() is left alone — it feeds the human-readable Filter.toString(), not the wire.

Key areas for review

• DateUtil.RFC3339 — the formatter itself; the fraction handling is the part worth a second look
• The read path is deliberately untouched. All four parse sites use OffsetDateTime.parse, whose default formatter treats seconds and fraction as optional, so it already accepts both spellings and data written by older clients still loads. This is what makes the change safe to ship without a migration.

Testing

The reason no existing test caught this: every date test seeded from OffsetDateTime.now(), which practically never has second and nano zero. The new tests use literals.

• Rfc3339DateTest — 26 cases: formatting across minute-boundary/millis/nanos/non-UTC/negative offsets, round-trip through the reader, the old truncated form still parsing, all eight filter comparison paths (including createdAt()/lastUpdatedAt(), which take OffsetDateTime only and so had no String workaround), the array operand, and the three InsertManyRequest shapes.
• JSONTest — five OffsetDateTime rows; the file had none. Each row asserts both directions.
• DataITest.testDataTypes and SearchITest.test_filterCreateUpdateTime now use minute-boundary values, so the existing round-trip and filter assertions guard the regression against a real server.

Verified the tests fail without the fix — with src/main reverted, the JSONTest rows fail with expected:<"2024-03-01T00:00[:00]Z"> but was:<"2024-03-01T00:00[]Z">.

Locally green: 418 unit tests, and DataITest + SearchITest + OrmITest against a container (48 run, 3 skipped by version gates).

Breaking changes

None. Public API is unchanged; DateUtil.toRFC3339 is additive, and the wire format only becomes more standards-compliant.

Closes #605

🤖 Generated with Claude Code

https://claude.ai/code/session_01WmY5dAGWCccWDoqkKNC2JU

[orca-security-eu]

Orca Security Scan Summary

Status	Check	Issues by priority
Passed	Infrastructure as Code	0   0   0   0	View in Orca
Passed	SAST	0   0   0   0	View in Orca
Passed	Secrets	0   0   0   0	View in Orca
Passed	Vulnerabilities	0   0   0   0	View in Orca

[Copilot]

Pull request overview

This PR fixes OffsetDateTime wire serialization to always produce RFC 3339-compliant timestamps (notably always including seconds), preventing server-side rejections for minute-boundary values like 2024-03-01T00:00:00Z.

Changes:

• Add DateUtil.toRFC3339(OffsetDateTime) backed by a custom DateTimeFormatterBuilder formatter that always prints seconds while preserving sub-second precision.
• Update all affected gRPC/REST marshalling sites (filters and batch insert shapes) to use DateUtil.toRFC3339(...) instead of OffsetDateTime.toString().
• Add/adjust unit + integration tests to cover minute-boundary timestamps and ensure round-tripping/parsing behavior remains compatible.

Reviewed changes

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

Show a summary per file

File	Description
src/main/java/io/weaviate/client6/v1/internal/DateUtil.java	Introduces RFC 3339 formatter + toRFC3339 and updates Gson adapter write path.
src/main/java/io/weaviate/client6/v1/api/collections/query/Filter.java	Uses DateUtil.toRFC3339 for date filter operands (scalar + array).
src/main/java/io/weaviate/client6/v1/api/collections/data/InsertManyRequest.java	Uses DateUtil.toRFC3339 for OffsetDateTime marshalling (scalar, list, array).
src/test/java/io/weaviate/client6/v1/internal/Rfc3339DateTest.java	New focused unit tests for formatting, round-trip parsing, and marshalling at all relevant call sites.
src/test/java/io/weaviate/client6/v1/internal/json/JSONTest.java	Adds JSON serialization expectations for OffsetDateTime including minute-boundary and fraction/offset cases.
src/it/java/io/weaviate/integration/SearchITest.java	Adjusts integration test to use minute-boundary timestamps to guard the regression in filters.
src/it/java/io/weaviate/integration/DataITest.java	Adjusts integration test to use minute-boundary timestamps to guard the regression in writes/round-trips.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[dudanogueira]

Looked into the Locale/DecimalStyle point — thanks, it sent me down a useful path, but the premise does not hold and toFormatter(Locale.ROOT) would not have addressed it.

The locale is not what selects the digits. DecimalStyle is, and a DateTimeFormatterBuilder always starts from DecimalStyle.STANDARD regardless of the locale it is given. Measured on JDK 25:

DecimalStyle.of(hi-IN-u-nu-deva) = DecimalStyle[०+-.]
DecimalStyle.STANDARD            = DecimalStyle[0+-.]

plain toFormatter()              -> 2024-03-01T00:00:00Z
withLocale(deva)                 -> 2024-03-01T00:00:00Z
withDecimalStyle(of(deva))       -> २०२४-०३-०१T००:००:००Z

So the mechanism the comment describes is real, but nothing here reaches it: only an explicit withDecimalStyle(...) changes the digits, and neither toFormatter() nor withLocale(...) does. Setting the default FORMAT locale to hi-IN-u-nu-deva, ar-EG-u-nu-arab or bn-BD-u-nu-beng leaves the output ASCII either way.

Rather than a no-op change I have added the invariant as a test (208f9ec4) — test_digitsAreAsciiInAnyLocale formats through DateUtil.toRFC3339 under those three locales. It has teeth: giving the formatter a locale-derived decimal style makes it fail with

[hi-IN-u-nu-deva] expected:<"[2024-03-01T00:00:00]Z"> but was:<"[२०२४-०३-०१T००:००:००]Z">

which is the only route to the problem as described. Unit suite green: 419 tests.