search: day-precision date comparisons are off at the boundaries (eq matches nothing; ge excludes the day itself; lt/le include the next midnight)

[angela-helios]

Found during the #448 manual sanity pass over Synthea data (SQLite backend, main @ 2026-07-30). Month- and year-precision date searches behave correctly; day-precision comparisons are wrong at every boundary.

Repro

Load a Patient with birthDate: "1995-10-02" (cohort below has 10 patients; dates listed at the end).

Query	Expected	Actual	Broken semantics
/Patient?birthdate=1995-10-02	1	0	eq range comes out empty
/Patient?birthdate=eq1995-10-02	1	0	same
/Patient?birthdate=ge1995-10-02	7	6	ge excludes the named day (acts like gt)
/Patient?birthdate=le1995-12-31	4	5	le includes a patient born 1996-01-01 (closed bound at next midnight)
/Patient?birthdate=lt1996-01-01	4	5	lt includes the boundary day (acts like le)
/Patient?birthdate=1995-10	1	1	month precision OK
/Patient?birthdate=1995	2	2	year precision OK
/Patient?birthdate=ge1995-10-02&birthdate=le1995-10-02	1	0	consistent with broken ge

Reading the pattern: the comparisons use the wrong end of the day-precision parameter interval — ge/lt compare against the parameter's end where the spec needs its start, and le closes its upper bound exactly at the next day's midnight (so le1995-12-31 captures 1996-01-01T00:00). eq, built from both bounds, ends up empty. Per FHIR date search semantics, a day-precision parameter is the interval [00:00, 24:00) of that day and eq/ge/le/gt/lt are defined against the resource value's own interval.

Chained variants inherit the bug (/Condition?patient.birthdate=1995-10-02 → 0 with matching data present).

Cohort birthdates: 1975-03-21, 1991-09-26, 1994-10-03, 1995-10-02, 1996-01-01, 1998-09-28, 2003-06-30, 2005-10-25, 2011-11-28, 2022-05-07.

Found on SQLite; other backends not yet checked (the #448 pass will). Worth checking the shared date-range translation rather than the backend, given chained search reproduces it.

Part of the #448 sanity pass.

[angela-helios]

The R4 parameter sweep widened this: second-precision datetime eq is broken too, not just day precision. Searching a resource by its own stored timestamp matches nothing:

MedicationRequest?authoredon=2016-01-23T13:07:42-04:00   → 0  (value taken from the stored resource)
DiagnosticReport?issued=1997-08-28T07:07:42.291-04:00    → 0
Provenance?recorded=2026-08-01T13:07:42.291-04:00        → 0
ImagingStudy?started=2017-03-27T04:56:12-04:00           → 0

…same for MedicationAdministration?effective-time, ExplanationOfBenefit?created, DocumentReference?date — every datetime-typed parameter the sweep could exercise with a real stored value. Whatever the fix is, it should cover the whole precision ladder (instant ⊂ day ⊂ month ⊂ year); month and year are the only rungs that work today.