A2P SMS quiet hours define the stretch of local time, typically late evening to morning, during which marketing SMS to recipients in a given jurisdiction must not be delivered. Send-time optimization (STO) is the broader practice of picking the delivery hour at which recipients tend to open and act on a message. Both look like simple scheduling on the surface, and both break in exactly the same way: a timer that pins the send window to UTC drifts against recipient-local clocks as daylight saving moves an hour earlier or later, and a message that waited for a favorable window lands inside a blocked one. This post walks through the quiet-hours definition, the recipient-local-time math, a worked DST failure, and how to configure send windows and regulatory gates in Devotel Orbit as tenant-side controls the operator sets explicitly.
Quiet hours, STO, and why non-US markets enforce a shorter window
Quiet hours are the blocked span of local time during which a jurisdiction prohibits or an operator chooses to forbid A2P (application-to-person) SMS marketing delivery. For a recipient in the US, a common baseline aligns with the federal telemarketing norm of no calls or texts before 8 AM or after 9 PM: an 8 AM → 9 PM allowed window. Other markets move the blocked stretch further into the day, and their regulators treat the per-recipient-local rule as the operative fact rather than a negotiating point:
- India (DLT-registered A2P traffic): most operators honor a 9 AM → 9 PM window, and much of the regulated promotional traffic must complete inside that corridor. Recipients in India receive marketing SMS only during those twelve hours, never around the clock.
- Brazil (CGNAT + carrier rules): consumer protections around outbound marketing often map operator windows closer to 8 AM → 8 PM, narrower than a US baseline, and violating hours invites carrier-level throttling rather than a single fine.
- GCC (United Arab Emirates, Saudi Arabia, others): observance of daily quiet hours is standard, and promotional traffic during the local blocked hours results in dropped or flagged messages rather than delayed retries.
- European Union: ePrivacy and national implementations vary, but most markets treat late-evening and early-morning marketing with the same seriousness as unsolicited contact. Advising a 9 AM → 8 PM window is the conservative posture.
Send-time optimization sits on top of this baseline: instead of just avoiding the blocked hours, STO picks the hour within the allowed span where engagement is historically highest. A recipient in a timezone whose clock reads 10:15 AM at send time gets the message, even if the UTC moment is the middle of the night for the operating team. Orbit's omnichannel messaging evaluates quiet-hours windows and send-time windows against the recipient's local time, not the sender's clock, per the recipient-local rule in the quiet-hours configuration guide.
The math for timers: recipient-local, never UTC-pinned
Every Orbit quiet-hours and send-time rule is evaluated against the recipient's local time: the timezone the recipient's phone number (a US area code or E.164 country code, or an explicit recipientTimezone hint) resolves to, because statute and regulation key on the recipient's experience, not the sender's convenience. The full resolution chain is documented in the quiet-hours configuration guide: caller hint, US area code mapping, country-code representative zone, then the org default or org-configured unknown_timezone_policy when none resolved.
UTC-pinned timers break in exactly this way: UTC never shifts, and recipients do. When a send window is stored as a UTC offset ("hold until 14:00 UTC"), daylight saving alters what that UTC moment means on the recipient's clock. A message scheduled for a 10:00 AM recipient-local time on a UTC-pinned timer becomes either 9:00 AM or 11:00 AM as the DST clock slides, and over the seasonal shift the drift accumulates an hour in the direction the DST change moved. Recipients get the message an hour early or an hour late relative to the intended hour. The allowed-window check a strict jurisdiction makes at the destination carrier fails the message, and recipients receive the message inside their blocked quiet hours.
The rule that holds is the one the docs state outright: quiet hours are recipient-local time at the recipient, not at the sender or the server. Any waiting message whose timer pins UTC drifts off the intended recipient-local hour by an hour or more around a DST change. Fixing the timer means moving the send-time expression to a recipient-local construct, a recipient timezone + local hour pair, before the message ever waits.
A worked DST failure
Hypothetical: an operator sends a weekly marketing SMS to recipients in New York at 10:00 AM recipient-local. The send window is stored as "14:00 UTC" (chosen in summer, when America/New_York is UTC-4).
Daylight saving ends on the first Sunday of November. America/New_York moves from UTC-4 (EDT) to UTC-5 (EST). The stored 14:00 UTC now falls at 9:00 AM recipient-local. The intended 10:00 AM slot moved one hour later than stored; the stored UTC moment falls one hour earlier on the recipient's clock. An operator whose window was "8:00 AM → 11:00 AM recipient-local" discovered that November that the UTC-pinned timer now tries to fire at 9:00 AM recipient-local instead of 10:00 AM recipient-local, and the change fails the carrier's allowed-window guard at the destination.
The repair is not adjusting the UTC offset; it is storing the send window as a timespec on the recipient's timezone (daily at 10:00 in America/New_York, for example) and letting the scheduler resolve the UTC instant at fire time. Orbit's evaluation model expresses the quiet-hours and send-time rule this way natively. An operator setting a window in the quiet-hours settings never has to reason about UTC shift because the rule is carried in recipient-local terms.
How timezone-aware send windows compose with regulatory gates as tenant-side configuration
Quiet hours are a tenant-side gate inside the bigger compliance stack. In Orbit, the send-gates reference frames quiet hours as the first check in a multi-layer gate that also runs do-not-call lists, prior-consent state, and the broader set of regulatory controls. Each of these is tenant-configured: the operator decides how strict to be, but the platform enforces the tenant-set rule deterministically at send time.
Instructionally this means an operator sets a quiet-hours window in one of two ways:
- Org-wide channel gate: a per-channel toggle with its own start and end hour, applied to every send on that channel, set in org settings (see organization settings). This lets the same account carry a stricter window for SMS and a looser one for email, or run SMS on 9 AM → 8 PM but accept email on 8 AM → 9 PM.
- Campaign fallback window: a single org-wide default that drip and journey sends use when the campaign row has no explicit window, exposed via the quiet-hours settings endpoints or Settings → Campaign limits → Default quiet hours in the dashboard.
Both knobs layer under explicit-campaign windows: a campaign that carries its own quiet_hours_start / quiet_hours_end wins over the fallback, and the fallback wins only when the campaign row has nothing. Tenant-side is the operative idea; compliant send-time behavior is a controlled choice the operator owns, and the platform's enforcement is the mechanics that make that choice deterministic. For the reason tenant-side matters, the compliance handbook send-gates reference lists the remaining gates (DNC, RND, emergency stop, and consent checks) that join quiet hours at the same evaluation point.
An Orbit operator setting up a new market usually wants the org channel gate on SMS paired with a campaign fallback tuned to that market's legal window. The global CPaaS messaging reach guide covers the registration prerequisites (10DLC in the US, DLT in India, sender-ID pre-registration across the EU and GCC), and the omnichannel comparison framework scores how a platform evaluates jurisdiction rules on one hand and maintains shared contact records across channels on the other.
Frequently asked questions
What is A2P SMS quiet hours?
A2P (application-to-person) SMS quiet hours are the blocked stretch of local time, typically late evening through early morning, during which a jurisdiction prohibits, or an operator chooses to forbid, marketing SMS delivery. In the US the familiar window is 8 AM → 9 PM as a federal baseline; regulated and conservative international windows are narrower (9 AM → 9 PM or 9 AM → 8 PM) depending on the destination.
Are quiet hours evaluated against the recipient's timezone or the sender's?
Quiet hours are evaluated against the recipient's local time, the timezone resolved from the recipient's address. Orbit resolves the recipient's timezone using a chain of caller-supplied hint, US area code, E.164 country code, or org default, then applies the allowed-window and quiet-hours rule against that zone rather than the sender's or server's time.
Why do DST shifts break UTC-pinned send-time timers?
UTC never shifts; recipients do. When a waiting message pins a send window to UTC, a daylight saving change shifts the recipient-local hour by one, so the intended local send-hour slides and the stored UTC moment falls an hour early or an hour later on the recipient's clock. DST-proof timers express the schedule as a recipient-local timespec, not a UTC instant.
How do quiet hours combine with other regulatory gates in Orbit?
Quiet hours sit alongside do-not-call, consent, and regulatory checks as one of the layers in the enforcement stack in Orbit's send-gates model. All of these are tenant-configured: the operator chooses the posture (quiet hours on SMS with consent carve-outs on other channels, for example), and the platform enforces whatever the tenant chose deterministically at send time.
Where do I set the quiet-hours window in Orbit?
Two places, both tenant-side: the org-wide per-channel gate in organization settings covers every send on the channel you enable, and the campaign fallback window gives drip and journey sends a default (in the dashboard at Settings → Campaign limits → Default quiet hours or via the /api/v1/campaigns/quiet-hours/settings endpoints). A campaign's own window beats the fallback, and the fallback only applies where the campaign row is empty.
Do STO windows and quiet-hours windows overlap?
Yes, deliberately. Quiet hours define the blocked span; send-time optimization picks the delivery hour inside the allowed span. Orbit evaluates both against recipient-local time, so an STO choice that is legal inside one destination's window stays legal there, even when another destination imposes a tighter constraint.