tapp/filament-timezone-field
A Filament form select field for picking timezones, with options to filter by country or region, switch display language, and use GMT instead of UTC. Install via Composer and add TimezoneSelect::make('timezone') to your resource schema. Compatible with Filament 3.x, 4.x and 5.x.
Architecture fit. tapp/filament-timezone-field is a thin, single-purpose UI component library for Laravel Filament admin panels. It ships a form field (TimezoneSelect), a table column (TimezoneColumn), and a table filter (TimezoneSelectFilter), all of which extend Filament's native primitives. It carries no persistence layer, no migrations, and no service-provider side effects beyond Filament registration. That makes it an easy architectural fit for any project already on Filament — it slots in exactly where you'd otherwise hand-roll a Select::make('timezone')->options(DateTimeZone::listIdentifiers()). The value proposition is real but narrow: it standardizes timezone UX (offsets, localized names, country/region scoping, browser auto-detection) that teams repeatedly reinvent.
Integration feasibility. Trivial to adopt. Composer require, import three classes, done. Compatibility matrix is explicit and healthy — branch 3.x covers Filament 3/4/5, and 2.x covers Filament 2. The only runtime dependency of note is symfony/intl (for localized timezone names via ->language()), which is normally already present in Laravel stacks. Risk of adoption friction is low.
Technical risk. The dominant risk is not technical but supply-chain and longevity: 57 stars, zero dependents, and a single-maintainer pattern (most PRs from @andreia). For a component this small, that's tolerable, but it means you are betting on a hobby-scale package for a user-facing input. The underlying logic is largely a wrapper over PHP's DateTimeZone and native Filament selects, so a fork or in-house replacement is cheap if the package stalls. Secondary risks: (a) implicit behavior of ->getTimezoneFromBrowser() — a JS-dependent hydration path that already produced a "Component not found" regression in v3.0.13, signaling edge cases on auth/SPA pages; (b) offset/UTC-vs-GMT display semantics differing from what downstream consumers (reporting, scheduling) expect; (c) timezone identifier drift as IANA tzdata updates — the package inherits whatever the PHP DateTimeZone supports.
Key questions. Which Filament version(s) are in scope today, and is there a 3→4→5 upgrade on the roadmap that would force coordinated bumps? Do we need localized names (i.e., is symfony/intl already a dependency)? Is the stored column a raw IANA identifier (preferred) or a display-formatted string? Who owns the fork fallback if upstream goes dormant? Does getTimezoneFromBrowser() fit our SPA/auth flow given its known regression history?
Stack fit. Assumes a Laravel app with Filament admin panels and a timezone column in the data model. The package is presentation-only — it does not define storage. The integration contract is therefore: the database column must store a canonical IANA timezone identifier (e.g., America/New_York), while the field/column handle formatting for display. This separation is the single most important convention to enforce.
Migration path. Two paths, depending on current state:
tapp/filament-timezone-field:"^3.0", replace ad-hoc Select fields with TimezoneSelect, add TimezoneColumn and TimezoneSelectFilter to tables. Near-zero risk.Compatibility. Pin the major version to the Filament major in use (3.x → Filament 3/4/5; 2.x → Filament 2). Watch symfony/intl constraints — v3.1.0 relaxed this to allow ^8.0, so pinning ^3.1 avoids unnecessary resolution conflicts during Laravel upgrades. Confirm tzdata version and PHP DateTimeZone behavior match expectations for any zones with DST edge cases.
Sequencing. (1) Normalize/validate the underlying column and add a test asserting only canonical IANA identifiers are stored. (2) Introduce TimezoneSelect in one resource as a canary. (3) Roll out TimezoneColumn/TimezoneSelectFilter to tables — these are read-only presentation and lowest risk, so they can precede form changes if you want early visual wins. (4) Only then opt into ->getTimezoneFromBrowser() on resources where auto-detection is genuinely valuable, and scope it away from auth/SPA pages given the known regression. (5) Layer in ->byCountry(), ->byRegion(), ->language(), and offset-hiding per resource to match each audience.
Maintenance. Low ongoing effort, but not zero. Because the package wraps Filament internals, Filament major upgrades (3→4→5) will require verifying the field/column/filter still render and hydrate correctly. Budget a small compatibility check per Filament major. The package's own upgrade cadence has been responsive (Filament 4 support in v3.0.10, Filament 5 in v3.0.12), which is reassuring for a small project.
Support. Internal support burden is small and mostly conceptual: users ask "why does it show UTC vs GMT?" or "why doesn't my browser zone apply?" Mitigate with clear UX copy and defaults (timezoneType('UTC') is the default; GMT is opt-in). External support is community-grade — no vendor SLA — so treat the repository as maintainer-dependent and keep a fork plan. Since there are zero public dependents, expect thin community answers; your team is de facto the support tier.
Scaling. Negligible runtime scaling concern: options are computed in PHP and rendered as a native Filament select; there's no database or network amplification. Two scaling notes: (a) full timezone lists are long — use ->searchable() and consider ->byCountry()/->byRegion() to keep selectors usable at scale; (b) if the form is heavy, ensure option lists aren't rebuilt per row in large tables — verify column rendering with formattedOffsetAndTimezone() on high-row-count tables, and be aware of the historical empty-value exception (fixed in v3.0.5) as a guardrail.
Failure modes. Most likely: ->getTimezoneFromBrowser() silently not populating (JS not attached on auth/SPA pages, the v3.0.13 regression class), or overwriting intent — mitigated by "only fills when empty" behavior. Data-integrity failure if the column ever stores a display-formatted string instead of an IANA ID; enforce with a validation rule and a test. Rendering failure on empty column values was a real bug (v3.0.5) — add coverage for nulls. Localization failure if symfony/intl is missing or tzdata is stale. All are low-severity and recoverable; none affect non-Filament surfaces.
Ramp-up. Developer ramp-up is measured in minutes: the README is complete and example-driven, and the API mirrors Filament select conventions. The real onboarding cost is team convention — agreeing that the DB stores IANA identifiers, that display formatting lives in the column, and which resources opt into browser hydration. Document those three rules once and the package is effectively invisible to future contributors.
How can I help you explore Laravel packages today?