How to make follow-ups respect business days without hard-coding one timezone

The naive-date bug

Adding a fixed number of raw hours (like 72) to a timestamp ignores both timezones and weekends. A sequence created Friday afternoon in one timezone, targeting recipients in another, can easily compute a 'next touch' that lands during the recipient's weekend or the middle of their night — technically three days later, practically the wrong moment.

Why timezone has to be stored explicitly

The correct timezone for scheduling is the recipient's or the campaign's stated assumption — not the sender's location, and not the server's default. This needs to be a stored value per contact or per campaign, set deliberately, rather than inferred from wherever the system happens to be running.

Compute the next business window at execution time

Rather than pre-calculating a fixed future timestamp when the sequence is created, the next eligible send time should be computed at the moment it's actually needed, using the stored timezone and a business-day rule (skip weekends, respect a defined sending window like 8am-6pm local). This avoids baking in an assumption that goes stale between scheduling and execution.

Walking through the Friday scenario

A sequence created Friday in Ho Chi Minh City (UTC+7) targets US East Coast prospects (UTC-4/-5). Adding 72 raw hours from Friday afternoon Vietnam time lands early Monday morning US time — inside the recipient's business week, but potentially before their working day starts, or worse, landing on what is still their Sunday depending on the exact hour. Computing from the recipient's actual calendar avoids this drift.

Set a latest-send cutoff

Even with business-day logic correct, a message computed to land at, say, 6:58pm recipient-local can still feel like an odd-hours send if the window boundary is loose. A defined cutoff — no sends after a set local hour, deferred to the next business morning instead — keeps the timing feeling deliberate rather than automated.

What this doesn't solve

Most systems at this scale don't track regional holiday calendars precisely, and building that out is a meaningfully bigger project than business-day logic alone. It's worth treating as a known, accepted gap rather than something a simple weekday check will quietly cover.

Storing timezone versus inferring it

The most reliable source for a contact's timezone is an explicit field set at signup or import time, if the data pipeline captures it. Where that's not available, inferring from company headquarters location or area code is a reasonable fallback, though it should be treated as lower-confidence than an explicit value and revisited if better data becomes available later.

Daylight saving transitions are a real edge case

A sequence spanning a daylight saving transition can see its computed local-time offset shift by an hour partway through, if the scheduling logic captured a fixed UTC offset instead of a proper timezone identifier that accounts for DST rules. Using a timezone database identifier (like America/New_York rather than a fixed UTC-5) avoids this drift automatically.

Common mistakes worth checking for directly

Two patterns show up repeatedly in systems that get this wrong: storing a fixed UTC offset instead of a proper timezone identifier (which breaks across daylight saving transitions), and computing the next send time once at scheduling and never re-evaluating it if the sequence is delayed or retried for any reason.

A quick audit worth running periodically: pick a handful of scheduled sends at random and manually verify the computed local time actually falls within the intended business window for that recipient. This catches drift that's easy to miss in code review but obvious once you look at the actual output.

Why this is worth the extra engineering effort

A scheduling bug that occasionally sends at an odd local hour is easy to dismiss as a minor cosmetic issue, but it's also one of the more visible signs to a recipient that a message came from an automated system rather than a deliberate, considered outreach. Getting the timezone and business-day logic right is a small technical investment that meaningfully affects how professional the sequence appears on the receiving end.

It's also worth building this check once into a shared utility used everywhere the system schedules a send, rather than reimplementing the timezone and business-day logic separately in multiple places, which is a common way for the same class of bug to quietly reappear in a part of the codebase that wasn't updated along with the rest.

A relatively small amount of upfront engineering care here avoids a class of bug that's otherwise easy to miss in testing, since it only shows up for certain timezone combinations and certain days of the week — exactly the kind of edge case that slips past casual manual testing.

Building this once, testing it against a few real timezone pairs, and reusing it everywhere sends are scheduled is a better investment than fixing the same class of bug repeatedly across different parts of the system.

Field checklist

• Store the recipient's or campaign's timezone explicitly — never infer it from the sender's location or server default.
• Compute the next eligible business-day send time at execution, not as a fixed timestamp set when the sequence is created.
• Skip weekends based on the recipient's local calendar day, not the sender's.
• Set a defined local sending window (for example 8am-6pm) with a cutoff that defers to the next morning instead of sending late.
• Treat regional holiday calendars as a known, unhandled gap rather than assuming weekday logic covers it.
• Test the scheduling math explicitly across a timezone pair with a large offset before trusting it in production.