Date Format Validation Inconsistency Between Insertion and Querying

Support
1

Description:
We’ve observed an inconsistency in schema validation for timestamp fields between insertion and query operations in Weaviate.

Details:

  1. Our schema includes a created_date property (type: date/timestamp)
  2. An object was successfully inserted with the timestamp: 2025-06-09T11:30:45.578126325Z (note the 9-digit microseconds)
  3. During querying/retrieval, the system performs strict format validation requiring microseconds to be ≤6 digits
  4. This mismatch causes a ValueError during retrieval despite successful insertion

Expected Behavior:
We would expect either:
a) Consistent validation (rejecting >6 digit microseconds at insertion), or
b) Consistent handling (accepting the format at both insertion and query)

Impact:
This creates potential data consistency issues where:

  • Data appears valid during insertion
  • Becomes inaccessible during querying
  • May require manual data cleanup

Environment:
Weaviate version - 1.28.11
Python client version - 4.5.7

Reproduction Steps:

  1. Create collection with timestamp property
  2. Insert object with timestamp containing >6 digit microseconds
  3. Attempt to query the object

Exception
ValueError: time data ‘2025-06-09T11:30:45.578126325Z’ does not match format ‘%Y-%m-%dT%H:%M:%S.%f%z’

Question
From JDK17 , the Instant.Now() from java.time util return datetime with 9-digit microseconds.
We get this error from that data only. Is this a issue from python’s datetime module?

2

Hey @Dharanish,

If I understood the issue correctly—please feel free to correct me if not:

Weaviate currently shows inconsistent behavior in timestamp precision :

  • Insertion: Accepts timestamps with 9-digit microseconds (e.g., from Java’s Instant.now())
  • Querying: Expects strict 6-digit microseconds (e.g., Python’s datetime precision)

This leads to a data integrity issue where data inserted successfully becomes unqueryable later, particularly throwing a ValueError during filtering operations.

To break it down:

  • Java’s Instant.now() → 2025-06-09T11:30:45.578126789Z
  • Python’s datetime → 2025-06-09T11:30:45.578126Z

This mismatch result in failed queries if not truncated beforehand.

Could you please file an issue on Weaviate GitHub and will try to get a core engineer to look at:

Actually, make sure to upgrade to the latest version of Weaviate (currently v1.31.0) and re-test—there may have been changes in how timestamps are handled.

Best regards,

Mohamed Shahin
Weaviate Support Engineer
(Ireland, GMT/UTC timezone)

1 Like