All tools
LOCAL CLOCKS / UTC DISPATCH / CONTROLLED LEARNING

Respect the clock.
Measure the lift.

Turn audience time zones, preferred windows, delivery capacity, and an explicit outcome metric into an auditable send schedule.

  • DST-aware zones
  • Capacity queue
  • Test sizing
PLANNING STATE / NOT A GUARANTEED BEST TIME

The cohort schedule fits the supplied constraints.

117,000 recipients across 4 named-timezone cohorts on August 4, 2026.

100%weighted timing fit25.6 points above one global send
No universal weekday or hour wins every audience.

The model honors the preferences entered here; it does not infer them. Use historical click, conversion, or reply evidence, then validate timing with randomized tests.

Recipients117,000

4 audience cohorts

Named zones4

IANA identifiers, not fixed offsets

Queue span9.6h

0 recipients delayed

Test requirement45,210

22,605 per timing variant

STRATEGY COMPARISON

Local delivery preserves more of the supplied intent.

LOCAL-TIME COHORTSRecommended plan
100.0%

Weighted fit after throughput queuing. Each cohort starts from its own calendar date and preferred local hour.

Dispatches4
Maximum queue delayOn time
ONE GLOBAL DISPATCHComparison
74.4%

Best half-hour UTC candidate across the supplied cohorts, before provider throughput duration.

UTC start2026-08-04 15:00Z
Recipients outside window0
DISPATCH MANIFEST

What the provider should schedule.

COHORTRECIPIENTSLOCAL STARTUTC STARTQUEUEFIT
EuropeEurope/London
18,000
Aug 4, 9:00 AMpreferred 9:00 AM
2026-08-04 08:00Zfinish 2026-08-04 08:21Z
On time100%
US EastAmerica/New_York
42,000
Aug 4, 10:00 AMpreferred 10:00 AM
2026-08-04 14:00Zfinish 2026-08-04 14:50Z
On time100%
US CentralAmerica/Chicago
26,000
Aug 4, 10:00 AMpreferred 10:00 AM
2026-08-04 15:00Zfinish 2026-08-04 15:31Z
On time100%
US PacificAmerica/Los_Angeles
31,000
Aug 4, 10:00 AMpreferred 10:00 AM
2026-08-04 17:00Zfinish 2026-08-04 17:37Z
On time100%
GLOBAL-SEND CLOCK

One UTC instant creates many local experiences.

Best modeled start2026-08-04 15:00Z

The strip scores every half-hour UTC candidate. Brighter cells preserve more recipient-weighted proximity to each cohort's preferred hour and operating window.

00
01
02
03
04
05
06
07
08
09
10
11
12
13
14
15
16
17
18
19
20
21
22
23
US East11:00 AMAmerica/New_York87% fit
US Central10:00 AMAmerica/Chicago100% fit
US Pacific8:00 AMAmerica/Los_Angeles74% fit
Europe4:00 PMEurope/London9% fit
RANDOMIZED HOLDOUT PLAN

Can this send support the timing claim?

Single-send sample is sufficient22,605required recipients per variant
Control timingPreferred local hour
Challenger timing+3h from control
Baseline → target3.20% → 3.68%
Available test pool46,800 total
Estimated sends needed1
Modeled incremental unique clicks112.3

Two-sided 95% confidence and 80% power planning approximation. Randomize within each timezone cohort, keep content and audience rules fixed, and analyze the declared primary outcome. Sequential peeking and many subgroup comparisons change the error rate.

SCHEDULE HANDOFF

Export assumptions, UTC dispatches, local clocks, queue effects, global comparison, and experiment sizing.

The optimizer schedules assumptions; it does not manufacture audience evidence.

Each cohort supplies a named timezone, size, preferred local hour, and operating window. The planner converts the local calendar target into UTC, queues overlapping work against capacity, and compares that plan with every half-hour candidate for one global dispatch.

Named zones preserve rule changes that a fixed UTC offset cannot.

America/New_York is a ruleset; “UTC−5” is only an offset. Daylight-saving and political changes can alter the relationship between a local clock and UTC, so schedules should store the intended local time, named zone, resolved instant, and the timezone-data version used by the sending system.

Optimize for a business-relevant action, not the easiest event to count.

Clicks, conversions, and replies are available because the best timing depends on the job of the message. Keep the metric definition, attribution window, denominator, and bot filtering stable. Delivery timing can also change unsubscribes and complaints, so review guardrails alongside lift.

Randomize within timezone cohorts and hold everything else constant.

A send-time test should compare timing, not two different audiences or messages. Predeclare the primary outcome and minimum effect, allocate recipients randomly inside each cohort, run both variants on comparable dates, and avoid repeatedly checking significance until a preferred result appears.

What is the universally best time to send email?+

There is no defensible universal hour. Message purpose, audience behavior, geography, work pattern, urgency, and client habits change the answer.

Why use named time zones instead of UTC offsets?+

Named zones carry daylight-saving and political rules. A fixed offset can be wrong when those rules change.

Should I optimize open rate?+

Open data can be useful directionally, but privacy features, image loading, bots, and client behavior can distort it. Prefer a stable outcome closer to the message goal when possible.

Why does throughput change local timing?+

A provider or account cap turns one scheduled instant into a delivery interval. Large or overlapping cohorts may finish meaningfully later than their requested local time.

Does a sufficient sample guarantee a useful result?+

No. Sample size is a planning approximation. Randomization, instrumentation, stable exposure, guardrails, and honest analysis still determine whether the result is credible.