Weave Code
Laravel Timezones Laravel Package
whitecube/laravel-timezones
Laravel Timezones offers a curated list of timezone identifiers plus validation, select options, and browser-based detection helpers. Easily set user timezones, localize dates, and generate timezone dropdowns in Laravel apps.
Store UTC dates in the database and work with custom timezones in the application.
Frequently asked questions about Laravel Timezones
- What does whitecube/laravel-timezones actually do?
- It is a single-purpose Laravel utility that lets you store UTC dates in the database while working with custom timezones in the application. It ships a curated timezone reference table, an Eloquent model, a publishable config file, and an artisan install command, plus helpers for validation, select options, and browser-based timezone detection. It sits purely at the presentation/localization layer and does not touch domain logic, queues, or the request lifecycle, so it can be added or removed without architectural ripple. If you only need raw identifiers, PHP's DateTimeZone::listIdentifiers() may already be enough.
- How do I install whitecube/laravel-timezones in a Laravel app?
- Run composer require whitecube/laravel-timezones, publish the config file, then run the package's install/seed artisan command to populate the timezones table. The service provider is auto-discovered, so no manual registration is required. Afterwards, verify the row count and the localized labels, and decide whether the seed runs as part of your CI/deploy bootstrap or is reproduced by your own migration and seeder.
- Does whitecube/laravel-timezones support Laravel 13?
- Version 1.4.0 is a compatibility-only release that widens framework support to Laravel 13 through two pull requests. Because release notes rarely distinguish between adding a new major and replacing an old one, open composer.json and confirm your current major (for example Laravel 12) is still inside the constraint. Check the PHP version floor in the same constraint matrix before pinning the package.
- How do I build a timezone dropdown in Laravel with this package?
- The package provides select options generated from its curated, queryable timezone list, so you can render a dropdown without hardcoding identifiers by hand. Localized timezone names come from the reference table, which is the main reason to choose this package over DateTimeZone::listIdentifiers(). Publish the config and seed the table first so the options resolve correctly.
- How do I store UTC dates but display them in the user's timezone?
- Keep timestamps in UTC in the database as usual and store the user's timezone identifier on their profile. Use the package's timezone list and validation rule to set that value reliably, then convert UTC to the user's zone at the presentation layer. The browser detection helpers can pre-fill the timezone for new or anonymous users.
- Does it detect the user's timezone automatically?
- Yes, the package includes browser-based detection helpers so you can pre-fill a user's timezone instead of making them scan a long list. Detection is a convenience, not a guarantee, so always validate the submitted identifier server-side against the package's list or validation rule before persisting it. Treating stored user preference as primary and detection as a fallback is the safer pattern.
- How do I validate a timezone input in Laravel?
- The package supplies timezone validation so submitted identifiers are checked against its curated list rather than accepted blindly. That keeps invalid or stale values from reaching the date rendering layer and producing wrong offsets. Apply it on any profile or settings form where a timezone is user-editable.
- How do I keep the timezone data from going stale?
- Treat package version currency and timezone data currency as two separate checks. The bundled reference data lags IANA tzdata releases, and a stale row can silently produce a wrong display offset after a jurisdiction changes its DST rules. Assign a named owner to watch upstream releases, which typically land one or two times per year, and have a way to detect staleness before a user reports it.
- Should I use this package or PHP's DateTimeZone::listIdentifiers()?
- If you only need a list of identifiers, PHP's built-in DateTimeZone::listIdentifiers() already covers you and the dependency is not justified. Choose whitecube/laravel-timezones when you need localized timezone labels, a queryable table, select options, validation, or browser detection helpers. It is small enough to vendor if the package is ever abandoned, so the exit cost is low.
- Does the timezones table get seeded automatically in CI and deployments?
- The package ships an artisan command that installs and populates the timezones table, but whether that runs automatically in your deploy or CI bootstrap is your decision. Package-managed seeding is the simplest path; reproduce the table with your own migration and seeder if you need fully reproducible environments. Either way, verify the row count and localized labels in a preview environment before shipping.
Weaver
How can I help you explore Laravel packages today?