Time-zone selector

When to use

User preferences / scheduling / log-display surfaces where the operator must pick a canonical IANA zone (not just a display offset). Defaults to the browser's resolved zone via Intl.DateTimeFormat().resolvedOptions().timeZone — overrides for users in multi-zone accounts.

Basic — searchable picker

Type to filter by city, region, or offset. Default value resolved from the browser's locale; the current-tz hint sits under the input. Composes select-ui[searchable] with no new primitive.

With live preview

The chosen zone's current local time updates in the description as the user changes the picker. Useful for "Send at" / "Schedule report" forms where the time-in-target matters more than the offset.

Composition rules

• Data from Intl.supportedValuesOf('timeZone') — browser-native, always current with the IANA database the browser ships. No external tz-data dependency.
• Label format: region/city · UTC±N — gives both the canonical identifier (for storage) and the human offset (for scanning). Users sort by either.
• Default from Intl.DateTimeFormat().resolvedOptions().timeZone — the browser's resolved zone is the right zero-friction default. Surface the value as a hint so users can confirm before saving.
• Recompute offsets per render — DST transitions move; cache the offset string at render time, not at boot. (Re-rendering on each open is cheap; the cost is the ~400-option list which we already accept.)
• For account-level multi-zone scheduling — pair with a second select-ui for the user's locale-zone vs the report-target-zone. Don't try to encode both into one picker.

Cross-references

• select-ui — base primitive ([searchable] flag is the load-bearing feature).
• relative-time-ui — companion for showing past/future timestamps in the chosen zone.
• Intl.supportedValuesOf MDN — data source.