> ## Documentation Index > Fetch the complete documentation index at: https://docs.orbit.devotel.io/llms.txt > Use this file to discover all available pages before exploring further. # Quiet hours across DST: crossover nights, Arizona and Hawaii, and the pre-launch preview > Verify your quiet-hours posture holds across daylight-saving transitions: the recipient-local rules that never move, the two non-DST US zones that change their relationship to everything else, worked Nov 1 / Mar 8 timelines, and the preview procedure to run before go-live. # Quiet hours across DST: crossover nights, Arizona and Hawaii, and the pre-launch preview Twice a year, US daylight-saving time shifts every recipient-local clock in your send window. If your quiet-hours posture was verified in October, verify it again before March 8 — and vice versa before November 1. This page is the operator walk-through for that verification: the rules that anchor the math, the two zones that break naive offset arithmetic, worked timelines for the two 2026 crossover dates, and the preview call that proves your window before a campaign launches. Quiet hours are a **tenant-owned posture** — the window start/end, the per-channel toggles, and the unknown-timezone fallback are all settings **you** write. The platform computes them with DST-aware math against the IANA timezone database, but which window you set is your call, and verifying it holds across a crossover is your runbook step. This page is not legal advice; have counsel re-verify your obligations. ## 1. The rules the math stands on Three rules decide every DST case. Once you hold them, no crossover surprises you: **Recipient-local interpretation.** The window is always evaluated against the time at the recipient's clock, resolved from the IANA timezone the platform maps from the NANP area code (or your `timezone_override` hint). A window of 08:00–21:00 means "8 AM to 9 PM where the recipient is," on whatever offset that zone is on today. **Behind-UTC regions.** "America is behind UTC" is only a summary. Each US zone carries *two* offsets — one standard, one daylight — and the crossover flips which one applies. A wall-clock window anchored to "behind UTC by 5 hours" is wrong for half the year; the evaluation works in local clock time precisely so the offset never enters the configuration. **Ambiguous windows.** On the fall-back night, one local hour exists twice (01:00–02:00 local, in most US zones). Policies that state a single-hour cutoff ("hold until 08:00") resolve to the next instant the local clock reads 08:00 — DST-aware math finds that instant in UTC correctly whether the day has 23, 24, or 25 hours. What you should never do is replicate the old integer-hour shortcut ("hold N hours, then send") anywhere in your own scheduling layer: on a 25-hour fall-back night that arithmetic reopens the window an hour early, and an 07:0x send sits inside TCPA quiet hours on the voice lane ($500–$1,500 statutory damages per call/message under the federal statute). The platform's own send-path deferral computes the *next UTC instant at which the recipient's local clock reads the window-open hour* — hold to `next_allowed_at` rather than re-deriving hours on your side. ## 2. The two zones US-only tenants stare at Arizona and Hawaii never observe DST. Everything they communicate with does. Your recipients in Phoenix and Honolulu keep one offset all year, so their relationship to a US-wide "send at 9 AM local" plan flips twice a year — the most common "my quiet-hours window is wrong" report after each crossover. | Zone | IANA name | Offset in winter (standard) | Offset in summer (daylight) | Drift across the year | | ------- | ------------------ | --------------------------- | --------------------------- | ------------------------------------------- | | Arizona | `America/Phoenix` | UTC−7 (MST) | UTC−7 (MST) | None — but Mountain neighbors move to UTC−6 | | Hawaii | `Pacific/Honolulu` | UTC−10 (HST) | UTC−10 (HST) | None — the mainland moves around it | Two consequences to keep on your checklist: * **Arizona matches its neighbors only half the year.** In winter, Phoenix shares the wall clock with Denver; in summer, with Los Angeles. A contact-CRM field stamped "Mountain" says nothing about the offset Phoenix is on today — let the platform resolve the zone from the area code, or pass the IANA name explicitly. * **Hawaii holds two DST-adjacent failure shapes.** A 21:00 recipient- local end hour closes against Honolulu at 07:00 UTC in winter but the *recipient's* 21:00 stays put — what changes is how your mainland-scheduled queues line up against it. If any internal job batches "send to Hawaii at 8 AM HST," that UTC instant moves by one hour across the crossover; schedule against the recipient-local target, not a fixed UTC time. The American Samoa (`Pacific/Pago Pago`, UTC−11, no DST) and Guam / Northern Mariana (`Pacific/Guam`, UTC+10, no DST) territories behave the same way — fixed offset, shifting relationship to the mainland. ## 3. Worked timelines: send on Nov 1 vs Mar 8 The two US crossover dates in 2026 are **March 8** (spring-forward, 23-hour day) and **November 1** (fall-back, 25-hour day). The tables show a `New York` recipient and a window-open hour of 08:00 local — the same shape your `next_allowed_at` value will carry. **Fall-back — dispatched Saturday Oct 31 at 22:00 EDT:** | Step | UTC instant | Recipient-local (America/New\_York) | | ------------------------ | ------------------------------------- | ----------------------------------------------------- | | Dispatch blocked | Oct 31 22:00 local = Nov 01 02:00 UTC | 22:00 EDT — outside window | | Crossover hits overnight | Nov 01 06:00 UTC | 02:00 EDT → 01:00 EST (25-hour day) | | Window reopens | Nov 01 13:00 UTC | 08:00 EST | | Correct wait | 11 hours | — (integer-hour math says 10 and opens an hour early) | **Spring-forward — dispatched Saturday Mar 7 at 23:00 EST:** | Step | UTC instant | Recipient-local (America/New\_York) | | ------------------------ | ------------------------------------- | ------------------------------------ | | Dispatch blocked | Mar 07 23:00 local = Mar 08 04:00 UTC | 23:00 EST — outside window | | Crossover hits overnight | Mar 08 07:00 UTC | 02:00 EST → 03:00 EDT (23-hour day) | | Window reopens | Mar 08 12:00 UTC | 08:00 EDT | | Correct wait | 8 hours | — (the DST jump *shortens* the wait) | A Phoenix recipient on the same nights never changes offset: the window reopens at 08:00 MST whether the mainland moved or not. The instant that is in UTC still shifts relative to a mainland queue — exactly the drift to audit. The send-path deferral these tables describe is regression-tested against both crossover directions (and a non-DST control zone) so the `next_allowed_at` your campaign reads is the 08:00-local instant, not the integer-hour approximation. ## 4. Verify with the preview before go-live Run the same read the send path runs. Do it **twice**: once on each side of the crossover if you can schedule ahead, or against a known post-crossover instant at minimum. The endpoint answers with the recipient-local hour it resolved, the window boundaries, and — when blocked — the DST-safe `next_allowed_at` ISO instant you hand to your scheduler. ```bash theme={null} curl -G "https://api.orbit.devotel.io/api/v1/compliance/quiet-hours/preview" \ -H "X-API-Key: dv_live_sk_your_key_here" \ --data-urlencode "phone=+14805551234" \ --data-urlencode "channel=voice" ``` ```json theme={null} { "data": { "allowed_now": true, "local_hour": 10, "local_timezone": "America/Phoenix", "window_start_local": "08:00", "window_end_local": "21:00", "reason": "in_window", "channel": "voice", "next_allowed_at": null } } ``` The pre-launch procedure for a window that covers Arizona or Hawaii recipients (or any DST-observing zone): 1. **Resolve the recipient set's zones.** Preview one recipient per distinct area code in the campaign. Confirm the reported `local_timezone` is the IANA zone you expect — Phoenix and Honolulu should read exactly those names, not a mainland alias. 2. **Check the posture on your campaign window.** Preview at a blocked local hour and confirm `next_allowed_at` lands at your configured window-open hour in local time, even when the response was generated across a crossover. 3. **Pin the decision in your runbook.** Store the preview request and its result next to the campaign launch checklist; recheck after the next crossover date if the campaign is still running. 4. **Fix the timezone, not the policy, when the zone is wrong.** A relocated number resolves to the wrong zone; pass your CRM's better knowledge via `&timezone_override=America/Phoenix` at preview, and persist the correct zone on the contact rather than relaxing your `unknown_timezone_policy`. If none of your recipients sits outside the federal statute surface, this verification is still worth the two preview calls: a send that opens an hour early on fall-back night is the most common DST defect across every channel, not only voice. ## See also * [Quiet hours configuration](/guides/quiet-hours-configuration) — the org gate, campaign fallback window, and `unknown_timezone_policy` knobs this page verifies. * [TCPA posture across SMS and voice](/guides/tcpa-quiet-hours-and-windows) — the full tenant-owned control map the voice window locks to. * [US state calling windows](/compliance/state-calling-windows) — the state overlays that stack with DST crossover. * [Troubleshooting: resolve dialing-window blocked calls](/troubleshooting/tcpa-window-blocked-calls) — triage for the 422 window family when the preview disagrees with your expectation.