Timezone Laravel Package

Product Decisions This Supports

• Feature scoping for anything "local time." Scheduling, reminders, quiet hours, billing cycles, availability windows, and calendar sync all need one primitive: is this a real timezone, and is it one we support? This package turns that into a declarative validation rule instead of ad-hoc in_array checks scattered through form requests.
• Constraining the addressable market, on purpose. The core Laravel package's value is the scoped variants — validating that a submitted timezone falls inside a given area or group (e.g. only Europe/*, or only the zones your support team can staff). That's a product decision ("we launch in EU + NA first") expressed as a validation rule rather than a support-process promise.
• Build vs. buy. The honest comparison is against ~5 lines of inline code: a closure rule wrapping DateTimeZone::listIdentifiers(). Buy only when you want the area/group/abbreviation constraints, or when you want consistency with the rest of the laravel-validation-rules/* family already in the codebase. If your need is the single "is this a valid identifier" check, note that Laravel ships a built-in timezone rule — do not add a dependency for that alone.
• Data-quality decisions at intake. Every timezone string that enters via public API, CSV import, SSO profile sync, or a client SDK is an input you don't control. Validating at the boundary is cheaper than reconciling null/garbage timezones later, when they've already been baked into stored timestamps and scheduled jobs.
• Roadmap sequencing. Adopting this is a low-cost enabler: once timezone capture is validated and normalized, region-aware onboarding, localized notifications, and per-tenant reporting windows become incremental work rather than a schema migration.

When to Consider This Package

Adopt when:

• You accept timezone input from a source you don't fully trust (API, import, third-party profile) rather than a fixed <select> you control.
• You need to restrict valid timezones to a continent/area or a DateTimeZone group — the genuine differentiator over the built-in rule.
• You need timezone abbreviation validation for display or legacy-system interop.
• You're already using other packages in the laravel-validation-rules/* family and want one idiom for all of them.

Look elsewhere (or do nothing) when:

• The requirement is only "valid IANA identifier" — use Laravel's built-in timezone rule and skip the dependency.
• You need offset/DST arithmetic or conversion. This is a string-validity package, not a time library; that's Carbon's job.
• You need tzdata freshness decoupled from PHP release cadence, historical timezone lookups, or pinned tzdata versions — evaluate brick/date-time or a dedicated tzdata package instead.
• You need a searchable, human-labelled timezone picker — that's a UI/data concern (CLDR / Intl), not a validation rule.

On release 1.7.0: a minor bump with no documented breaking changes, deprecations, or new features in the notes. Treat as routine maintenance — pin to ^1.7, skim the diff for Laravel/PHP support-matrix and dependency changes, and re-run your validation test suite. Low adoption risk, but the empty changelog is itself a signal: this is a small, single-maintainer utility. Budget for the possibility of reimplementing the two or three rules you actually use (an afternoon) as your exit plan.

How to Pitch It (Stakeholders)

To executives: A free, MIT-licensed, single-purpose validation package that closes a specific data-quality hole — invalid or unsupported timezones being written into the product and silently corrupting schedules, reminders, and reports. Cost is one Composer dependency; downside is bounded because the functionality is small enough to replace in-house if the package ever stalls. No vendor lock-in, no licensing cost, no infrastructure change. The business value is narrower blast radius when we launch local-time features in new regions.

To engineering: One composer require, zero configuration, no service provider to register, no runtime cost beyond a lookup against PHP's own timezone list. Rule objects compose into existing Form Requests and can be unit-tested like any other rule. Use it for area/group-scoped constraints and imports; use Laravel's built-in timezone rule where scope is irrelevant; use Carbon for anything involving actual time math. Current release (1.7.0) is a minor bump with no breaking changes — pin it and move on.