Filament Daterangepicker Filter Laravel Package

Product Decisions This Supports

• Build vs. buy on date filtering. A production-grade range picker is not a one-day ticket: dual calendars, preset ranges, keyboard entry with format validation, month/year granularity, timezone conversion, time pickers with increments, week numbers, dropdown z-index handling inside modals and slide-overs, and ARIA/keyboard accessibility. This package collapses that into a composer require plus a fluent field definition. The decision it supports is: do we spend engineering weeks on a solved UI primitive, or on the reporting features that sit on top of it?
• Scoping a reporting/analytics epic. Presets (->ranges([...])), defaultLast7Days(), defaultThisMonth(), and useRangeLabels() turn "give users a date filter" into a concrete, demoable slice. It supports committing to reporting work in a roadmap without a design-plus-frontend dependency.
• Granularity as a product requirement. monthPicker() and yearPicker() support genuinely different products: billing periods (m/Y), fiscal-year reporting (Y), and subscription/cohort windows. Without these, finance-adjacent requests get deferred or hacked into text fields.
• Query-cost governance. maxSpan(['months' => 1]), disableCustomRange(), and curated ranges() are levers a PM can use to bound expensive report queries and steer users toward the windows the product actually supports — a UX decision, not an infra one.
• Data-correctness decisions in dashboards. Release 5.0.7 separates display timezone (FilamentTimezone) from storage timezone (config('app.timezone')). Before that, any app that set a display timezone silently mis-bucketed rows in the first hours of a local day. PM-relevant: date filters that are quietly wrong are worse than no date filter, because they erode trust in every number on the screen. If your product shows local times over UTC storage, this release is a correctness requirement, not a nice-to-have.
• Upgrade sequencing. The v3/v4 → v5 migration is documented with a deprecation table (displayFormat() → format(), jQuery/Moment.js removed in favor of Alpine/Day.js). That makes the cost of staying on an older Filament auditable rather than open-ended.
• Standardization. One filter component across every resource panel instead of three bespoke implementations gives consistent behavior and one place to fix bugs.

When to Consider This Package

Adopt when most of these hold:

• The application is Filament v4 on Laravel. The package tracks Filament's styling and APIs closely; verify the version pin against your Filament constraint before planning around it.
• You have multiple admin/reporting surfaces that all need date windows, or repeated user requests for "just show me last month."
• You specifically need one of the non-obvious capabilities: month or year granularity, predefined range presets, dual state (useDualState('start_date', 'end_date') to bind separate Livewire properties), modal/slide-over compatibility, or timezone-aware filtering over UTC storage.
• You want a native Alpine.js/Day.js component rather than dragging in a jQuery/Moment-based picker.
• You need an escape hatch for non-standard queries — modifyQueryUsing() on the filter covers cases the default whereBetween doesn't.

Look elsewhere, or budget explicitly for ownership, when:

• You are not on Filament, or you are pinned to an older Filament major you can't move. The package's value is its native integration; outside that it's just a date picker you'd reimplement.
• You need comparison analytics — "this period vs. previous period," cohort retention, funnel windows, rolling averages. This package gives you a range; the comparison logic is yours to build.
• The filter must live in a customer-facing UI, not an admin panel. The component is styled for Filament and assumes Livewire; that's a different design language and a different accessibility bar.
• You require a vendor SLA or commercial support. This is a single-maintainer MIT package with modest adoption (178 stars, no listed dependents). The mitigation is real — small surface area, permissive license, forkable — but it is a mitigation, not an equivalent.
• Your i18n requirements exceed Day.js locales (e.g., specific RTL or regional calendar behaviors). Localization is present; validate against your actual locales rather than assuming.
• Your org has a strict dependency-minimization policy. Be honest in the tradeoff: you're accepting a low-adoption dependency in exchange for weeks of avoided UI work.

How to Pitch It (Stakeholders)

To executives: We can ship date-range filtering across reporting screens in days instead of weeks, with no licensing cost (MIT). It delivers the things users actually ask for — "last 30 days," "this month," billing periods, fiscal years — plus keyboard entry and accessibility that we would otherwise under-invest in. Risk is bounded: it's MIT-licensed, small, and forkable, so the worst case is we own a few hundred lines, not a re-platforming. The recent 5.0.7 release also fixed a timezone bug where filtered reports could silently omit the first hours of a local day — that's a trust issue with dashboard numbers, and it's already fixed for us.

To engineering: Native Filament v4 field and filter, Alpine.js + Day.js (no jQuery/Moment), teleports the dropdown to <body> to survive modal and slide-over z-index stacking. Filters support modifyQueryUsing(fn($query, $start, $end, $raw) => ...) so anything non-standard is a closure, not a fork. Timezone handling now mirrors Filament's own DateTimePicker: getTimezone() for display, getSystemTimezone() for storage, with a systemTimezone() override for columns stored outside the app zone. Dual state lets start and end map to separate Livewire properties. Upgrade path from v3/v4 is documented with an explicit deprecation table.

To design/product: Presets and useRangeLabels() mean users pick "Last 30 Days" instead of doing date math — fewer support tickets and more predictable queries. maxSpan() and disableCustomRange() let us constrain the picker to ranges the product actually supports. Month and year modes cover billing and fiscal reporting without a bespoke UI.

The ask: Timebox a one-resource pilot (roughly a day), validate the timezone configuration against production data — especially if FilamentTimezone::set() is in use — and confirm the package version against our Filament constraint. If the pilot holds, standardize on it for reporting surfaces and delete any bespoke date filters.