- How do I install tapp/filament-timezone-field in a Laravel Filament app?
- Run composer require tapp/filament-timezone-field:'^3.0' and then add TimezoneSelect::make('timezone') to your Filament resource or page schema. There are no migrations, no config file to publish, and no manual service provider registration thanks to Laravel package discovery. The field drops into any existing form without affecting the rest of your components.
- Which Filament versions does this timezone field support?
- Version 3.x of the package supports Filament 3.x, 4.x, and 5.x, and that is the current documentation track. If you are still on Filament 2.x you should use the package's 2.x branch instead. Broad Filament compatibility means upgrading the panel does not force you to replace the field.
- What value does the timezone field store in the database?
- The field stores the timezone identifier as a plain string, typically an IANA name such as America/New_York or Europe/Madrid. Because the value is a simple string, a standard string column plus Laravel's timezone validation rule is usually enough, with no casts or lookup tables. If business rules need historical offset snapshots, store the offset separately, since IANA identifiers always reflect current rules.
- How do I display timezone names in another language?
- Pass an ISO 639-1 code to ->language('es') and the option labels are rendered with localized names via symfony/intl. Without it the field falls back to its default English labels. Keep in mind that this pulls symfony/intl into your dependency tree, which is worth checking if your project is strict about transitive dependencies.
- How can I limit the timezone options to a specific country or region?
- Use ->byCountry('US') for a single country or pass an array such as ->byCountry(['US', 'AU']) for several. For broader groupings, ->byRegion() accepts a value from the package's Region enum. Each restriction adds configuration surface, so only apply them where product requirements clearly demand it.
- How do I show GMT instead of UTC in the timezone labels?
- Call ->timezoneType('GMT') on the field to render labels using GMT rather than the default UTC. The change is cosmetic only and does not alter the value that gets saved, which remains the timezone identifier. You can combine it with ->language() and the country or region filters.
- Does searchable(), required() and reactive() still work on this timezone select?
- Yes. TimezoneSelect extends Filament's native Select component, so every fluent modifier you already use still applies, including searchable(), required(), reactive(), live(), afterStateUpdated(), and custom validation rules. You can even override the option list with ->options() if you need a hard-coded set. There is no bespoke API to learn beyond the package's own language(), timezoneType(), byCountry(), and byRegion() methods.
- Why is my timezone missing from the dropdown?
- The option list is generated from PHP's bundled IANA timezone database, which is refreshed through the server's tzdata rather than by the package itself. A stale tzdata package on the host or container image is the usual cause of a missing or oddly named zone. Update tzdata and PHP on the server, clear any cached config, and the entry will reappear.
- Does the package include a table column and filter as well as the form field?
- Yes. Alongside the TimezoneSelect form field, the package ships a TimezoneColumn for tables and a TimezoneSelectFilter for narrowing records. Both reuse the same value semantics as the field, so read and write paths stay consistent across a resource. They follow the standard Filament column and filter APIs, so existing table conventions apply.
- What does getTimezoneFromBrowser() do and is it safe to use in production?
- It detects the visitor's timezone on the client side and preselects it, and it is the only browser-dependent behavior in the package. It also has the most regression history, with fixes in v3.0.11 for options not loading on initialization and v3.0.13 for a Component not found error on auth and SPA pages. Adopt it deliberately rather than by default, and decide up front how a detected zone should behave when a stored value already exists.