Skip to content

fix: order legacy filter date range by parsed datetime instead of string comparison #9569

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
eeshsaxena wants to merge 1 commit into
base: preview
Choose a base branch
from
+7 −2
Open

fix: order legacy filter date range by parsed datetime instead of string comparison #9569

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
9 changes: 7 additions & 2 deletions apps/api/plane/utils/filters/converters.py
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -306,8 +306,13 @@ def _convert_date_value(self, field_name: str, values: List[str], strict: bool =
result = {}
if len(after_dates) == 1 and len(before_dates) == 1 and len(exact_dates) == 0:
# Simple range: one after and one before
start_date = min(after_dates[0], before_dates[0])
end_date = max(after_dates[0], before_dates[0])
# Order the bounds chronologically by comparing parsed datetimes, not the
# raw strings: _validate_date accepts non-ISO formats that do not sort
# lexicographically (e.g. "9/1/2023" vs "10/1/2023").
if dateutil_parse(after_dates[0]) <= dateutil_parse(before_dates[0]):
start_date, end_date = after_dates[0], before_dates[0]
else:
start_date, end_date = before_dates[0], after_dates[0]
Comment on lines +309 to +315

@coderabbitai coderabbitai Bot Aug 8, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🩺 Stability & Availability | 🟠 Major | ⚡ Quick win

🧩 Analysis chain

🏁 Script executed:

#!/bin/bash
set -euo pipefail

python - <<'PY'
from dateutil.parser import parse

naive = parse("2023-09-01")
aware = parse("2023-10-01T00:00:00Z")

assert naive.tzinfo is None
assert aware.tzinfo is not None

try:
    naive <= aware
except TypeError:
    print("Reproduced: mixed naive/aware datetime ordering raises TypeError")
else:
    raise SystemExit("Expected TypeError")
PY

Repository: makeplane/plane

Length of output: 218

🏁 Script executed:

#!/bin/bash
set -euo pipefail

FILE="apps/api/plane/utils/filters/converters.py"

printf '--- file size ---\n'
wc -l "$FILE"

printf '\n--- outline around date converter functions ---\n'
ast-grep outline "$FILE" --view expanded | sed -n '1,220p' || true

printf '\n--- relevant sections ---\n'
sed -n '220,330p' "$FILE" | nl -ba -v220

printf '\n--- dateutil import ---\n'
rg -n "dateutil_parse|_validate_date|_process_date_field|dateutil|parse" "$FILE"

Repository: makeplane/plane

Length of output: 244

🏁 Script executed:

#!/bin/bash
set -euo pipefail

FILE="apps/api/plane/utils/filters/converters.py"

printf '%s\n' '--- file size ---'
wc -l "$FILE"

printf '%s\n' ''
printf '%s\n' '--- relevant sections ---'
sed -n '220,330p' "$FILE" | nl -ba -v220

printf '%s\n' ''
printf '%s\n' '--- dateutil import and converter references ---'
rg -n "dateutil_parse|_validate_date|_process_date_field|dateutil|parse" "$FILE"

Repository: makeplane/plane

Length of output: 286

🏁 Script executed:

#!/bin/bash
set -euo pipefail

FILE="apps/api/plane/utils/filters/converters.py"

printf '%s\n' '--- file size ---'
wc -l "$FILE"

printf '%s\n' ''
printf '%s\n' '--- relevant sections lines 1-340 ---'
awk '{printf "%5d  %s\n", NR, $0}' "$FILE" | sed -n '1,340p'

printf '%s\n' ''
printf '%s\n' '--- dateutil converter references ---'
grep -En "dateutil_parse|_validate_date|_process_date_field|dateutil|parse" "$FILE" || true

Repository: makeplane/plane

Length of output: 16608

Normalize timezone awareness before comparing date bounds.

Mixed naive and timezone-aware date inputs can pass _validate_date, but ordering them at line 312 raises TypeError. For example, 2023-09-01;after parses to a naive datetime, while 2023-10-01T00:00:00Z;before parses to an aware datetime; naive <= aware is rejected by Python. Since _process_date_field only catches ValueError, this error escapes in both strict and non-strict conversion. Normalize both parsed bounds to the converter’s date/timezone policy before comparing, or raise ValueError explicitly for mixed awareness so the existing handler reports it. Add coverage for non-ISO ordering and mixed-awareness inputs.

🤖 Prompt for AI Agents 
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@apps/api/plane/utils/filters/converters.py` around lines 309 - 315, Update
the date-bound ordering logic around _process_date_field to handle mixed naive
and timezone-aware results from dateutil_parse without leaking TypeError:
normalize both parsed bounds according to the converter’s timezone policy before
comparison, or explicitly convert mixed awareness to ValueError so existing
strict and non-strict handling applies. Preserve non-ISO chronological ordering
and add coverage for both non-ISO bounds and mixed-awareness inputs.

self._add_rich_filter(result, field_name, "range", [start_date, end_date])
elif len(exact_dates) == 1 and len(after_dates) == 0 and len(before_dates) == 0:
# Single exact date
Expand Down