- How do I install webteractive/filament-browser-timezone in a Laravel app?
- Install it with Composer using composer require webteractive/filament-browser-timezone. Laravel package auto-discovery registers the service provider, so the package starts detecting the browser timezone on Filament page loads without extra setup. You can optionally publish the config if you need to change the session key or fallback behavior.
- Does webteractive/filament-browser-timezone support Filament v3, v4, and v5?
- Yes. The package is built for Filament v3, v4, and v5 through render hooks, and its documented compatibility matrix also spans Livewire v3/v4 and PHP ^8.2. Check the Composer constraints before upgrading a production Filament panel, because the support matrix is broad and the package has a small maintainer surface.
- How does the package detect the user's browser timezone?
- It detects the timezone client-side with Intl.DateTimeFormat().resolvedOptions().timeZone. A hidden Livewire component posts that value to the server, where the package stores it in the Laravel session under a configurable key. Filament resources, tables, forms, and widgets can then read the session value through the BrowserTimezone helper.
- Why is my Filament table still showing UTC on the first page load?
- Detection happens after the Filament page loads, so the first render may not have the browser timezone yet and can fall back to UTC or a prior session value. Unless the UI refreshes or the package triggers a re-render, date columns and form defaults can be one request behind. This is acceptable for many internal admin displays but not for workflows where the first render must be timezone-correct.
- How do I use the detected timezone in Filament tables, forms, and widgets?
- Use BrowserTimezone::get() to read the detected timezone, BrowserTimezone::has() to check availability, or BrowserTimezone::get('UTC') to provide an explicit fallback. In Filament tables you can pass it to a dateTime column with timezone(BrowserTimezone::get()), and in forms you can pass it to a DateTimePicker with timezone(BrowserTimezone::get()). The same helper is available in widgets and other backend Filament code.
- Is the browser timezone stored in the database or as a user preference?
- No. The package stores the detected timezone in the Laravel session only, not in a database column or persistent user profile field. That makes it a per-session convenience rather than a durable preference, so it is not reliable for cross-device consistency, audit trails, compliance timestamps, or customer-facing scheduling.
- How do I configure the session key or fallback timezone?
- Publish the package config and set the session key and fallback timezone explicitly if the defaults do not fit your application. The package is zero-config by default, but being explicit in staging and production makes the fallback behavior easier to reason about. Validate the chosen fallback against your intended UTC-storage and local-display policy.
- What happens if browser timezone detection fails or JavaScript is disabled?
- The package is designed with graceful fallbacks, so missing or unsupported browser timezone detection should not throw a visible error. However, the fallback can silently resolve to UTC, which may render dates incorrectly without a user-visible warning. Use BrowserTimezone::has() or BrowserTimezone::isValid() where correctness matters, and avoid relying on silent fallback for regulated, billing, scheduling, or audit workflows.
- How do I clear the stored browser timezone session value?
- Run php artisan filament:timezone:clear to clear the stored browser timezone value from the session. This is useful during testing, impersonation checks, or troubleshooting stale timezone values. After clearing it, the next Filament page load should detect and store the browser timezone again.
- Is webteractive/filament-browser-timezone production-ready for a Filament admin panel?
- It is a reasonable convenience layer for internal Filament admin panels, operations dashboards, and back-office date display where a per-session browser timezone improves usability. The code surface is small and MIT-licensed, so vendor lock-in is low and the package can be forked or replaced. Adoption risk is higher than code risk: it has very low GitHub adoption, no visible CI in the current repository state, and a single-maintainer profile, so pin it, test it, and avoid using it for customer-facing scheduling, financial effective dates, compliance timestamps, or any workflow that requires an auditable stored user timezone.