Legacy filter converter orders date ranges by string comparison, reversing non-ISO date inputs

Summary

LegacyToRichFiltersConverter._convert_date_value builds a date range by comparing the raw date strings with min() / max(), which only matches chronological order for zero-padded ISO YYYY-MM-DD values. The field validator (_validate_date) accepts any dateutil-parseable format, so a non-ISO input produces a reversed [start, end] range.

apps/api/plane/utils/filters/converters.py:

# _validate_date accepts any dateutil format
dateutil_parse(value)              # line ~178
...
# but the range is ordered by string comparison
start_date = min(after_dates[0], before_dates[0])   # line 309
end_date   = max(after_dates[0], before_dates[0])   # line 310

Why it is wrong

min/max on strings sorts lexicographically. That equals chronological order only for ISO YYYY-MM-DD. Since _validate_date uses dateutil_parse and passes many other formats (M/D/YYYY, D-M-YYYY, Jan 15 2023, non-zero-padded months, etc.), any such value can be ordered wrongly.

Example

Legacy filter for target_date:

["9/1/2023;after", "10/1/2023;before"]

Both pass _validate_date. Then:

• min("9/1/2023", "10/1/2023") -> "10/1/2023" (because '1' < '9')
• max(...) -> "9/1/2023"

So the range becomes ["10/1/2023", "9/1/2023"], i.e. start = Oct 1, end = Sep 1, which is reversed and matches nothing. Chronologically the correct range is Sep 1 -> Oct 1.

Scope

This only triggers when a non-ISO date string reaches this path. If every caller is guaranteed to send YYYY-MM-DD, it is latent, but the converter and its validator are internally inconsistent: the validator accepts formats the ordering logic then mishandles.

Suggested fix

Order by parsed dates rather than by string, e.g. parse both bounds with dateutil_parse and pick min/max of the datetime values (or normalize to ISO before comparing), keeping the emitted values in whatever format the rich filter expects.

Start in apps/api/plane/utils/filters/converters.py at LegacyToRichFiltersConverter._convert_date_value and compare its range ordering with _validate_date. Verify the provided non-ISO example first, then confirm the resulting range is chronologically ordered while emitted values remain compatible with the rich filter format.