Skip to main content

​
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–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. 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: Spring-forward — dispatched Saturday Mar 7 at 23:00 EST: 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.
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