Describe the bug
Exact-match metadata filters like '==' and 'in' compare ISO datetime values as raw strings instead of normalized datetimes. Because of that, equivalent timestamps such as '2025-02-03T12:45:46Z' and '2025-02-03T12:45:46+00:00' do not match, even though they represent the same moment.

Error message
No error is thrown. The bug is silent: matching documents are simply not returned.

Expected behavior
Equivalent ISO datetime values should match consistently across equality-style filters (==, !=, in, not in), just like they already do for ordering filters such as >= and <.

Additional context
This affects the Python-side filtering path used by document_matches_filter and InMemoryDocumentStore. In practice, it can cause silent recall loss when stored metadata uses Z but filters are built from Python datetime.isoformat() values using +00:00.

To Reproduce

1. Store a document with meta.date = "2025-02-03T12:45:46Z".

2. Filter with:

   {"field": "meta.date", "operator": "==", "value": "2025-02-03T12:45:46+00:00"}

3. Observe that no document is returned.

4. Repeat with:

   {"field": "meta.date", "operator": "in", "value": ["2025-02-03T12:45:46+00:00"]}

5. Observe that it also misses the document.

FAQ Check

• Have you had a look at our new FAQ page?

System:

• OS: macOS
• Haystack version: current local source checkout