Filament Dcat Filters Laravel Package

Product Decisions This Supports

• Reporting and dashboard accuracy bets. This release fixes a genuine correctness bug: date-mode range filters against datetime columns previously emitted to <= '2024-01-15', silently dropping every record after midnight on the end date. Any product surface backed by date-range filtering — admin dashboards, exports, invoicing periods, activity reports — was under-reporting the final day. That is a decision-grade defect, not cosmetic polish.
• Build vs. buy on filtering infrastructure. A package that ships range filters, date-column semantics, indicator/aggregate queries, and timestamp conversion paths is covering the unglamorous 80% of list-and-report plumbing. This release is evidence the vendor is maintaining edge semantics (timezone/boundary handling) that in-house teams routinely get wrong and rarely test.
• Roadmap enablement for date-scoped features. Correct full-day boundary handling unblocks features stated in human terms: "last 7 days," "this month," "January 1 through January 15." Product specs can now be written in calendar language and translated to the package directly, instead of engineering quietly appending 23:59:59 at every call site.
• Risk posture on dependency trust. A 1119-test / 1692-assertion suite with new regression cases added alongside the fix signals maintenance hygiene. This supports a "adopt and depend on it" recommendation rather than "vendor it and freeze."
• Reduced bespoke work. The from > to auto-swap means the UI no longer needs to defend against inverted ranges, removing a validation rule from the product spec and a class of user-facing errors.

When to Consider This Package

Adopt when:

• Your product exposes user-driven date range filtering over Eloquent models, especially on datetime/timestamp columns where "end date" must mean the full day.
• You need indicator/summary queries (counts, aggregates) over the same filters as your list views — consistency between the table and the totals is a common PM-visible bug source, and a single filter layer avoids it.
• You want boundary semantics centralized rather than reimplemented per endpoint.
• Your team is small enough that maintaining filter primitives in-house is a poor use of capacity.

Look elsewhere or proceed cautiously when:

• You need timezone-aware or multi-timezone day boundaries. This fix hardcodes 00:00:00/23:59:59, which is correct for a single application timezone but will not resolve "the user's local day" for a globally distributed user base. Confirm storage timezone and app timezone alignment before relying on it.
• Sub-second precision matters (event telemetry, financial ledgers): 23:59:59 excludes 23:59:59.500. If you have high-frequency data, this boundary is not fully closed.
• You require auditable, contractually specified semantics — pin the version and add your own regression tests regardless.
• Your filtering needs are trivial (a single whereBetween) or extremely custom (complex boolean filter trees, faceted search) — the abstraction may cost more than it saves.

Note: this is the first assessment on record; the package's scope is inferred from the release notes (RangeFilter, dateColumn(), indicator queries, toTimestamp()), so treat the above as a provisional adoption view pending a full API review.

How to Pitch It (Stakeholders)

To executives: We are evaluating a Laravel package that handles date-range filtering and summary reporting. Its latest release fixes a bug where reports silently omitted the final day of any selected date range — the kind of defect that produces wrong numbers in a board deck without throwing an error. The fix is small, covered by new automated tests (suite now at 1,119 tests), and non-breaking, so there is no migration cost or delivery risk. Recommendation: adopt for reporting surfaces and rely on the vendor for boundary handling rather than building it ourselves.

To engineering: Treat v2.1.2 as the minimum viable version for any date-range feature — earlier versions have a real off-by-one-day defect on datetime columns in date mode, affecting both dateColumn() queries/indicators and the toTimestamp() path. The upgrade is additive and low-risk: boundaries now normalize to 00:00:00/23:59:59 and inverted ranges auto-swap, so remove any client-side 23:59:59 patching and range-order validation you added as workarounds. Two known constraints to design around: boundaries are fixed to application timezone (not per-user), and the 23:59:59 ceiling drops sub-second records — raise both if we take on multi-region users or high-frequency event data.