Laravel Timezones Laravel Package

Product Decisions This Supports

• Localization / scheduling roadmap: Any feature that lets users pick a timezone — scheduling, reminders, availability windows, reporting cut-offs, notification preferences — needs a canonical, consistently ordered timezone list. This package is the "list" layer behind those features, so it directly unblocks the next round of i18n and scheduling work.
• Build vs. buy: The alternative is a hand-maintained config/timezones.php or ad-hoc DateTimeZone::listIdentifiers() calls scattered across controllers and form requests. The package is a few hundred lines of glue we would otherwise rewrite and then forget to keep aligned; buying (adopting) it removes a class of "one screen shows 'US/Eastern', another shows 'America/New_York'" bugs.
• Standardization decision: Using one source for timezone identifiers across validation rules, API responses, and dropdowns makes data consistent by construction — a prerequisite for any future migration to storing canonical IANA identifiers rather than free-text offsets.
• Framework upgrade planning: v1.4.0 adds Laravel 13 support (via two independent contributions, including Laravel Shift's automated compatibility PR). This tells us the maintainer tracks Laravel releases promptly, which is a concrete input into our own "can we upgrade Laravel this cycle?" decision — dependencies like this one won't be the blocker.
• Scope control: The package is deliberately narrow (list generation and grouping for form/API presentation). It is not a timezone conversion or DST-logic library — decisions about storing, converting, and rendering user-local times still belong to us, and we should not assume the package covers them.

When to Consider This Package

Adopt when:

• We have (or are about to build) UI or API surfaces where a user selects a timezone — settings pages, scheduling forms, onboarding, notification preferences.
• We need consistent grouping/labeling (e.g. grouped-by-region lists) for select inputs without hand-maintaining a config array.
• We want timezone identifiers validated against a canonical list rather than accepting arbitrary strings.
• We are on a supported Laravel version and want a zero-config, low-surface-area dependency rather than a full timezone framework.
• Laravel upgrade cadence matters to us — as of v1.4.0, support extends through Laravel 13, so adopting now doesn't create an upgrade cliff next cycle.

Look elsewhere when:

• We need conversion, offset math, DST arithmetic, or recurring-event timezone handling — reach for Carbon/a dedicated temporal library instead; this package is not that.
• We only ever display a fixed list of two or three timezones for a single-region product — a constant is simpler than a dependency.
• Our architecture is API-only with timezones supplied by the client as IANA identifiers already validated upstream — the value is marginal.
• We cannot accept any third-party dependency on the critical path of form rendering without a security/maintenance review; then vendor a trimmed copy instead.

How to Pitch It (Stakeholders)

Executive summary: A small, actively maintained open-source Laravel package that supplies the canonical timezone lists our user-facing forms and APIs need. The new v1.4.0 release is a compatibility update adding Laravel 13 support, with no breaking changes and no new configuration burden. It keeps our scheduling and localization features moving without custom code, and — importantly — it is not a blocker for our next Laravel upgrade: a new contributor plus Laravel Shift's automated compatibility PR landed this support, which is a good signal on maintenance responsiveness.

For engineering: Drop-in dependency, no migration required. Provides timezone identifiers/grouped lists for select inputs and validation. Low blast radius: it does not own persistence, conversion, or DST logic, so it can be swapped or vendored in an afternoon. Upgrade path is clean through Laravel 13.

Ask: Approve adding it to the dependency budget and standardize all timezone-select implementations on it; flag any feature requiring actual time conversion as out of scope for this package.