Timezones and quiet hours: stop automation arriving at the wrong moment

Store the audience timezone

“9 AM” is incomplete on its own—9 AM where? The first fix is to store a timezone for the person receiving or acting on the output, not the server, and not you as the person who created the task. Store it as a named zone such as Europe/London, not a fixed offset like UTC+1.

The reason the name matters: a named zone carries its own daylight-saving rules, so a 9 AM job stays at 9 AM local even after the clocks move. A fixed offset does not—set UTC+1 for London in July and the same “9 AM” report arrives at 8 AM once autumn returns the city to UTC+0. To judge you got it right, confirm the saved value shows a place, and check that a run scheduled across a clock-change date still reads 9 AM local on both sides. The trade-off to accept: the recipient’s zone is correct for delivery, but you may still think about when the work runs in your own time—so keep those two clocks separate, which is the next step.

Separate run time from delivery time

These are two different questions, and merging them is what produces 2 AM pings. Decide when the agent should prepare the work, and, separately, when it may notify a person. Fresh inputs often land overnight, so the agent can compile a report at 6 AM and hold the notification until the recipient’s day begins—less delay, no midnight buzz.

Why it helps: the value of a report and the courtesy of its timing pull in opposite directions unless you decouple them. You judge it by two checks—the delivery time matches the recipient’s morning, and the prep time matches when the inputs are actually complete. The failure case is tying “notify” to “run,” so an overnight job pings at 2 AM; the opposite failure is delaying the run so far that the report is stale by the time anyone reads it. The trade-off: holding delivery adds a little latency, so a genuine real-time alert—an outage, a payment failure—should not be held. Route those on their own path rather than into the morning digest.

Define quiet-hour behavior

Quiet hours are only useful if the agent knows what to do with the updates it would have sent. Decide the four behaviors below up front, and phones already model the pattern: a do-not-disturb window, an urgent level that can break through, and a scheduled summary that batches the rest.

• Hold ordinary notifications until quiet hours end, rather than delivering silently and hoping.
• Allow only named urgent events through—a specific, short list, not a vague “important.”
• Bundle held updates into one summary when the window ends, instead of releasing a burst.
• Show which timezone the rule uses, so “quiet until 7 AM” is never ambiguous.

You judge this by what arrives after a quiet night: one digest, not twelve pings, and only the events you pre-named broke through. The common failure is marking everything urgent so the bypass swallows the quiet window entirely—if all events are exceptions, there are no quiet hours. The mirror failure is holding a real outage alert behind the digest. The trade-off is exactly that dial: the more you let bypass, the less the window protects.

Handle teams in several regions

When one output serves people in different regions, a single send time cannot be everyone’s morning. You have two workable shapes: create a delivery window per region, or publish to a shared dashboard that people pull from without any push notification. Avoid the tempting middle—one “global morning” pinned to headquarters—because it is convenient for whoever set it up and nobody else.

Why it matters: a fixed 9 AM at your desk is the small hours for a teammate eight zones away, and repeated night pings train people to mute the agent entirely. To judge it, check that each region receives its digest inside its own working day and that no one is notified during their night. The failure case is defaulting to the founder’s clock and quietly exporting the interruption abroad. The trade-off: per-region windows add a little setup, while a pull dashboard removes push pressure but relies on people remembering to look—choose based on whether the update is something they must see or something they can check.

Preview the next three runs

Before you enable any schedule, look at the next three actual dates and their local times. Reading a rule—“every weekday at 9 AM”—hides the surprises; a rendered preview shows them. This is the cheapest check in the whole setup and it catches the mistakes that are hardest to notice in production.

Why three concrete runs beat one rule: daylight-saving shifts, weekends, and public holidays only appear when the rule is turned into real timestamps. Judge it by whether the three previews land where you expect, and pay special attention to any run that crosses a clock change—it should still read 9 AM local, not 8 or 10. The failure case is subtle and common: two regions move their clocks on different dates, so a cross-timezone gap you thought was fixed silently widens or narrows for a couple of weeks each spring and autumn. The trade-off is trivial—a minute of previewing now against a mystery 2 AM delivery, and a confused client, later.