A QUERY date condition needs a typed date literal, not merely a quoted display string. The source column must also contain compatible date values.
Use the query-language date syntax
For date values in column A and one header row in A1:C100, =QUERY(A1:C100,"select A, B where A >= date '2026-11-01'",1) selects records from the stated date onward.
The keyword date and year-month-day literal identify the comparison type. This is different from comparing a date column with the text ’11/01/2026′, whose meaning is ambiguous.
Inspect the source column’s actual type
Check whether the inputs are numeric dates or imported strings. QUERY’s majority-type rule can make minority text dates null. Reformatting the display alone does not guarantee a type conversion.
If the column contains timestamps, consult the query language’s datetime literal and align the comparison type deliberately. Keep the source’s time-zone interpretation consistent before assigning records to reporting days.
Test both boundaries
Use a known record before the start, one on the start date, and one afterward. For a closed reporting period, an exclusive next-period boundary can avoid accidentally excluding later times on the final day.
Confirm the header count and selected column identifiers. If no rows return, inspect these assumptions before wrapping the query in a blank fallback. Retain raw imported dates while parsing them in a helper field, and flag ambiguous inputs rather than making them appear verified. A syntactically valid date condition is useful only when the source records represent the intended calendar dates.
References
Reviewed against the linked official product guidance on November 3, 2026. Features, limits, screen labels, and access can vary by account, platform, region, and organization policy.