Fixed — date filters silently dropped rows when a display timezone was set
getSystemTimezone() returned FilamentTimezone::get(). That is Filament's display timezone — core reads it for date-time columns, entries and pickers, and it falls back to config('app.timezone') when unset. The timezone a column is stored in is config('app.timezone'), which is what Eloquent writes with.
While nobody calls FilamentTimezone::set() the two resolve to the same value and nothing is wrong. The moment somebody sets it — the documented way to show local times over UTC storage — the conversion in apply() became a no-op: input and system resolved to the same zone, so the parsed dates kept their local offset, and Laravel binds them with format(), which does not convert. Local wall-clock then reached the query against UTC data.
Measured on a UTC column with the display set to Asia/Riyadh, filtering a single day:
bindings 2026-08-18 00:00:00 / 2026-08-18 23:59:59 (+03 wall-clock)
row stored 2026-08-17 22:00:00 (01:00 that morning in Riyadh)
returned excluded
Every row falling in the first hours of a local day was filed under the day before — silently, which is the worst way for a date filter to be wrong.
The change
getTimezone()now defaults toFilamentTimezone::get()— the zone the dates on screen are written in.getSystemTimezone()now returnsconfig('app.timezone')— the zone the column is stored in.
This matches what Filament's own DateTimePicker does.
Upgrading
No action needed, and nothing changes for you unless you call FilamentTimezone::set(). When it is unset it returns config('app.timezone'), so both getters resolve exactly as before.
FilamentTimezone
| 5.0.6 | 5.0.7 |
|---|---|---|
| unset (default) | input=UTC, storage=UTC | identical |
Asia/Riyadh, UTC column
| input=Riyadh, storage=Riyadh — wrong | input=Riyadh, storage=UTC — correct |
New systemTimezone() setter, for a column genuinely stored outside the application timezone:
DateRangeFilter::make('created_at')->systemTimezone('Asia/Riyadh');Covered by tests/TimezoneSeparationTest.php — five tests, four of which fail without the fix.