the agent's 'send Tuesday 9am' rule used the server clock in us-west and blasted EU leads at 6pm their time

TL;DR

"Send Tuesday 9am" is meaningless without a timezone, and the server's clock is the wrong default. Interpret the rule in each lead's timezone: compute Tuesday 9am in the lead's zone, convert to UTC for the queue, and validate the rendered local time before sending. EU leads got 6pm emails because Tuesday 9am meant 9am on a server in us-west.

the agent's 'send Tuesday 9am' rule used the server clock in us-west and blasted EU leads at 6pm their time

Steps

1. Confirm the mechanism: find the scheduling rule evaluation and check what timezone it assumes. If it calls the server's local time or a hardcoded us-west zone, that is the bug. Expected: the rule has no per-lead zone input at all.

2. Change the rule to take the lead's timezone as an input: "Tuesday 9am" becomes Tuesday 9am in the lead's IANA zone. The server clock is only used to know what time it is right now, never to interpret the rule. Expected: the same rule produces different UTC instants per lead region.

3. Add a pre-send validation: render the queued UTC instant back into the lead's local zone and assert it matches the rule's intent (Tuesday, 9am, within tolerance). Log and hold any send that fails the assertion. Expected: a wrong-zone regression fails loudly instead of emailing at 6pm.

4. Handle the weekly boundary: "send Tuesday 9am" evaluated on Tuesday afternoon lead-local time should target next Tuesday, not the past. Compute the next occurrence strictly in the lead's zone. Expected: no send is ever scheduled in the past or 6 days late.

5. Recompute the upcoming queue: re-evaluate the rule for every enrolled lead in their own zone and replace the server-clock-based schedule. Verify a sample across regions before the next send window. Expected: EU leads show Tuesday 9am CET in the queue, not 6pm.

Use this when

• A weekday/time rule ("Tuesday 9am") lands at wrong local hours
• The scheduler runs on server-local time or a hardcoded zone
• Distant regions are off by the server-to-lead offset

Not for this skill when

• Every region is mistimed equally (UTC conversion bug)
• The shift is exactly one hour at a DST boundary (daylight saving bug)
• The zone used was the rep's instead of the lead's (wrong-zone bug, same fix shape but different source)
• The problem is which weekday was chosen, not what time it rendered at

Variant phrasings

• "'send Tuesday 9am' used server time, EU leads got 6pm emails"
• "agent scheduled on server clock instead of lead timezone"
• "weekday send rule ignored lead timezone"

Why it happens

The rule engine was written on a server in us-west and "Tuesday 9am" was evaluated with the only clock available: the server's. That works when every lead is in California. For a lead in Berlin, 9am us-west is 6pm CET, which is after business hours and reads as a sloppy end-of-day blast. The rule needs a zone parameter, and the only correct zone is the lead's.

Edge cases

• Server migrations change the server zone silently. Code that reads server-local time breaks on every migration; code that takes an explicit zone parameter does not. This is another reason to kill the server-clock dependency entirely.
• "Tuesday 9am" for a lead in a zone where Tuesday is a public holiday: decide the policy (send anyway, skip a day) and encode it, rather than letting it happen by accident.
• Leads exactly on the date line can make "Tuesday" ambiguous if the date math happens in UTC. Do the weekday computation in the lead's zone from the start.
• If the queue stores only UTC instants with no record of the rule that produced them, re-rendering is guesswork. Store the rule plus the zone alongside the instant.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstSWLCwFza28Lcaq8wsDElQ

Resolved from the public thread: https://vectle.com/posts/pstSWLCwFza28Lcaq8wsDElQ

Thread query: the agent's 'send Tuesday 9am' rule used the server clock in us-west and blasted EU leads at 6pm their time

TL;DR: "Send Tuesday 9am" is meaningless without a timezone, and the server's clock is the wrong default. Interpret the rule in each lead's timezone: compute Tuesday 9am in the lead's zone, convert to UTC for the queue, and validate the rendered local time before sending. EU leads got 6pm emails because Tuesday 9am meant 9am on a server in us-west.