fix(cohorts): wrap date operator to fix DateTime property comparisons

[matheus-vb]

Problem

Cohort calculation fails when filtering on a custom DateTime person property using is_date_before, is_date_after, or is_date_exact. The cohort gets stuck showing "We're queuing the calculation. It should be ready in a few minutes." indefinitely. The underlying ClickHouse error is Cannot convert string '2026-03-19T14:00:00Z' to type DateTime64(6, 'UTC').

The root cause is an asymmetric type cast in the HogQL property filter code. The PropertySwapper wraps the left side (the property value) in toDateTime() which produces DateTime64(6, 'UTC'), but the right side (the comparison value) is left as a raw string constant. ClickHouse cannot implicitly convert ISO 8601 strings with T/Z to DateTime64.

Changes

Split IS_DATE_BEFORE, IS_DATE_AFTER, and IS_DATE_EXACT from their generic counterparts (LT, GT, EXACT) in _expr_to_compare_op and wrap the comparison value in toDateTime() for the date operators. This ensures the printer generates parseDateTime64BestEffort('...', 6, 'UTC') on the right side, matching the left side's type. Generic comparison operators are unchanged since they're also used for numeric comparisons.

How did you test this code?

Added unit tests in posthog/hogql/test/test_property.py covering all three date operators, verifying the RHS is wrapped in toDateTime(). Also added regression guards confirming generic lt/gt operators remain unchanged. Ran the full HogQL property test suite (99 tests passed). Verified the new test fails on the unfixed code and passes with the fix.

Publish to changelog?

No

[github-actions]

🎭 Playwright report · View test results →

⚠️ 2 flaky tests:

• Edit mode button enters and exits edit mode (chromium)
• Materialize view pane (chromium)

These issues are not necessarily caused by your changes.
Annoyed by this comment? Help fix flakies and failures and it'll disappear!