Summary
The transaction-history filter compares the end date at local midnight, so a transaction that occurs later on the selected end day is excluded — an off-by-one on the last day of the range. Surfaced while reviewing #671 (which fixed a different bug in the same cubit); this one is pre-existing and untouched by that PR.
Where
lib/screens/transaction_history/cubits/filter/transaction_history_filter_cubit.dart — _applyFilter. Bounds are applied inclusively via !isBefore / !isAfter, but a picked end date arrives as DateTime(y, m, d) (local midnight, 00:00:00).
Repro
- Have a transaction timestamped e.g.
2026-04-01 14:00 (local).
- Set the filter end date to
2026-04-01.
- Expected: the transaction is included (its day is within range).
- Actual: it is excluded —
txTime.isAfter(2026-04-01 00:00) is true, so the !isAfter inclusive check drops it.
Related concern
The same comparison path mixes a local-midnight bound against the stored timestamp; confirm the timestamps and bounds are compared in a consistent zone (local-vs-UTC drift can shift a tx across the boundary independently of the above). See the DateTime local/UTC equality trap the team has hit before.
Suggested fix
Normalize the end bound to the end of the selected day (e.g. endDate → 23:59:59.999 local, or < startOfNextDay) before the _applyFilter comparison, and align the zone of both operands. Add a regression test for a same-day-afternoon transaction at the end bound.
Scope note
Not a blocker for #671 — filing separately so the range-fix PR stays minimal.
Summary
The transaction-history filter compares the end date at local midnight, so a transaction that occurs later on the selected end day is excluded — an off-by-one on the last day of the range. Surfaced while reviewing #671 (which fixed a different bug in the same cubit); this one is pre-existing and untouched by that PR.
Where
lib/screens/transaction_history/cubits/filter/transaction_history_filter_cubit.dart—_applyFilter. Bounds are applied inclusively via!isBefore/!isAfter, but a picked end date arrives asDateTime(y, m, d)(local midnight, 00:00:00).Repro
2026-04-01 14:00(local).2026-04-01.txTime.isAfter(2026-04-01 00:00)is true, so the!isAfterinclusive check drops it.Related concern
The same comparison path mixes a local-midnight bound against the stored
timestamp; confirm the timestamps and bounds are compared in a consistent zone (local-vs-UTC drift can shift a tx across the boundary independently of the above). See the DateTime local/UTC equality trap the team has hit before.Suggested fix
Normalize the end bound to the end of the selected day (e.g.
endDate→23:59:59.999local, or< startOfNextDay) before the_applyFiltercomparison, and align the zone of both operands. Add a regression test for a same-day-afternoon transaction at the end bound.Scope note
Not a blocker for #671 — filing separately so the range-fix PR stays minimal.