Send timing must follow timezone and sleep

What it is

The clock on a push must be the recipient's timezone and sleep, not the server's, and not the campaign calendar. The same "morning send" is not morning in Tokyo and New York; for a night-shift worker, local 9:00 can still be mid-sleep. A wrong clock turns a daytime-tolerable arrival into an event that pulls someone out of sleep, and that accelerates whole-channel disable.

This is how the sender chooses an hour. It is not the product feature called quiet hours (that discussion is who may pierce, and how caps are counted per type), and it does not treat "don't cut in mid-subtask" as a sleep problem.

Why it happens

During sleep and deep rest, the cost of waking dwarfs a daytime glance. Sound and a lit screen cut a sleep stage; the emotional tag on the sender afterward is intrusion, not reminder. Campaigns like a single timezone because scheduling is cheap; each local person pays. Device timezone is the coarsest usable signal. Recent unlocks, charging, and focus state patch the gap between timezone and sleep: the zone can be right and a night-shift worker still gets called at "local morning."

"Send during work hours" cannot be hardcoded 9–18 either. Cross-zone teams, weekend on-call, and devices that travel move the clock. A cached stale zone will ring on the first night after landing with the old city's daytime.

Studying it

Assign the same copy to "sender business hours," "device-local daytime," and "recent activity window." Compare share of night arrivals, later master-off, and complaints tagged as waking someone.

Independent variables: clock source (server / device zone / activity window), whether the local sleep core is avoided, delay in updating zone after travel. Dependent variables: share of arrivals between local 23:00–7:00, disable rate after those arrivals, next-day open delay.

Lab participants arrive by day; they will not be woken. Use diaries, wearable sleep windows, or at least device focus/charging hours. Do not pick a send peak from global open rate—that peak can be another zone still awake and a trough for local sleepers.

Where it stops holding

Flights, security, and user-set alarms must be allowed to sound in sleep; that clock is the user's, not a campaign window. When someone explicitly wants "push as soon as it ships," latency beats sleep, but the default should still be silent; sound needs higher consequence. When zone cannot be read (web push, zone off), fall back to a more conservative window or silent delivery rather than firing on UTC. Public boards and warehouse scanners have no sleep; this entry does not apply.

Applying it

• Read device timezone before send and translate campaign windows into local daytime; do not drape one HQ clock over the whole population.
• Estimate a sleep core from recent unlock/charge distributions; do not send deferrable types inside that core.
• On the first local night after a zone change, constrain to the new offset, not the old one.
• Verify by converting a sample of sends into each user's local time and plotting a 24-hour arrival histogram. A peak still inside the local sleep core means the clock source is wrong; change it and watch master-off, rather than rewriting the copy as "good morning."

Related

• Within the group: H5.07.1 Crossing a frequency threshold shuts the whole channel · H5.07.3 Unsubscribe must be reachable from the notice
• Adjacent: H5.10 Push frequency and quiet hours · H5.02 Interruption cost and timing · H5.03 Do not disturb and focus
• Search terms: timezone-aware push · sleep window · circadian interruption