Filament Timezone Field Laravel Package

Product Decisions This Supports

• Build vs. buy on a "small but fiddly" UI surface. A timezone picker looks trivial and isn't: offset labels, localized names, country/region scoping, and browser-based defaults are each a small ticket. This package collapses them into one composer require, freeing the sprint for the parts of the feature that are actually differentiating.
• Shipping timezone capture into existing Filament admin panels. If our back office, customer portal, or internal ops tooling is Filament-based, this is a form component plus a table column plus a table filter — three surfaces for one dependency. That's a same-day story, not a roadmap item.
• Onboarding, settings, and "your local time" preferences. Every product with a scheduling, digest, quiet-hours, or reporting-window feature needs the user's IANA timezone. This gives us a validated, localized picker with a sensible default, which is the precondition for correct notifications and date-boundary logic downstream.
• Multi-region rollout and choice-overload reduction. ->byCountry(['US','AU']) and ->byRegion(Region::Australia) let us scope the list to markets we actually serve. That's a product decision (fewer wrong selections, less support load) we can express in one line of schema rather than a custom cascading widget.
• Localization commitments. ->language('es') via Symfony Intl means an i18n requirement doesn't force a bespoke component. This directly de-risks any "we're launching in LATAM/EU next quarter" commitment.
• Admin data quality and triage. TimezoneColumn formatting options and TimezoneSelectFilter improve support workflows — e.g. filtering users by region to debug "my digest arrives at midnight" tickets.
• Framework upgrade planning. Declared support for Filament 3.x/4.x/5.x on the same 3.x line means a timezone field is not a blocker in a Filament major-version upgrade. That is a real (if unglamorous) input to sequencing the upgrade.
• Explicit non-decision: this is not a scheduling or conversion engine. It captures and displays a timezone. DST-correct conversion, storage policy (UTC-everywhere), and rendering remain ours. Decide that separately and don't let a green "we added the field" signal imply the scheduling work is done.

When to Consider This Package

Adopt when:

• The stack is Laravel + Filament 3/4/5 and the need is a timezone input, column, or filter in an admin/panel context.
• We want it live in a day or two with ^3.0 pinned and a smoke test, versus a 3–5 day custom widget with tests.
• Localized timezone names, GMT-vs-UTC display, offset/name visibility, and country/region scoping are requirements (they're all supported out of the box).
• "Prefill from the browser unless a value is already set" is desired — getTimezoneFromBrowser() gives that behavior without custom JS.
• The cost of swapping it later is acceptable, which it is: it's one isolated form component wrapping Filament's Select, so lock-in is near zero.

Look elsewhere / handle in-house when:

• The app is not on Filament. This is Filament-specific; for a Vue/React/Inertia front end, use a JS-side timezone list instead of dragging in server-side UI plumbing.
• The real requirement is scheduling, recurrence, DST-safe conversion, or per-user display formatting of stored timestamps. Scope that as separate work; this package doesn't do it.
• We need geo-IP → timezone inference, country→timezone auto-derivation, timezone data version pinning, or a richer DST-aware UI. None of that is here.
• Vendor-risk policy is strict. Honest read of the signals: 57 stars, 0 dependents, a maintainer-and-a-few-contributors pattern, active releases (latest 2026-05-04) but unproven in the wild. Low blast radius (a single select field), so this is tolerable — but don't treat it as a foundation.
• We already maintain a shared internal form-component library; adding an external dependency for one field may be more governance overhead than the code it saves.

Adoption checklist before merge: pin ^3.0; confirm the symfony/intl constraint resolves against our locked Laravel/Filament versions; add a feature test asserting the stored value is a valid IANA identifier; verify getTimezoneFromBrowser() on our auth/SPA pages specifically (changelog v3.0.13 fixed a "Component not found" regression there — it's the known-sharp edge); decide and document the storage convention (store IANA name, render and convert at the edges) and a server-side validation rule.

How to Pitch It (Stakeholders)

To executives: This is a small, cheap, low-risk dependency that removes a recurring build task — a properly localized timezone picker with country/region filtering, list-column rendering, and browser-based defaults — from our backlog. It's a single form component for our Filament admin/panel stack, not infrastructure, so it carries no meaningful lock-in and can be replaced in hours if needed. It also keeps our Filament upgrade path open (3.x/4.x/5.x supported on one line). The honest caveats: it's a young, low-adoption package (small maintainer base, few public users), and it captures the user's timezone — it does not do scheduling or timezone conversion, which is a separate and larger decision.

To engineering: One composer require, one TimezoneSelect::make('timezone') in the schema, plus TimezoneColumn and TimezoneSelectFilter where useful. It extends Filament's Select, so searchable(), required(), reactive behavior and the rest of the standard API still apply. Options we care about: language(), timezoneType('GMT'), byCountry(), byRegion(), hideNames()/hideOffset(), getTimezoneFromBrowser(). Integration is roughly half a day including tests. What we own: server-side validation to a valid IANA identifier, the store-in-UTC/render-locally convention, and any DST-sensitive logic downstream. Watch the browser-prefill path on non-standard pages, and pin the version so a minor bump can't drift our Filament/symfony-intl constraints. If the dependency ever becomes a problem, the fallback is ~40 lines around DateTimeZone::listIdentifiers() — that's the entire risk envelope.