Daylight saving and email campaigns: review the transition week

Define the decision

The practical problem is a mismatch between an intended local hour and a stored or assumed offset. Some regions change clocks, others do not, and transition dates differ. Avoid hard-coding a universal seasonal calendar into campaign notes. Check the relevant dates for the regions in the actual audience.

Work through the procedure

1. List campaigns active across the upcoming transition and identify the timezone configured for each.
2. For the business day before and after the change, convert the opening and closing times into the recipient region. Include any region whose transition occurs in a different week.
3. Inspect pending follow-ups whose due time falls near the boundary. Distinguish the delay calculation from the allowed send window.
4. Record whether any schedule needs an intentional change. Leave a clear note explaining the recipient-facing reason, so another operator does not reverse it as an apparent mistake.

Worked example

The following is a synthetic example for this procedure, not a customer result or performance benchmark.

Transition audit
Audience: two regions with different clock-change dates
Campaign intent: recipient's business morning
Check dates: before first change, between changes, after second change
For each date: campaign opening → recipient local time
Action: adjust segmentation or window only if the intended experience changes

Read the result

The middle period is easy to miss: both regions may observe daylight saving yet temporarily differ from their usual offset relationship. Checking only winter and summer can therefore overlook a short scheduling mismatch. The worksheet is a planning control, not a claim about how every scheduler handles nonexistent or repeated local times.

Check before moving on

1. Use a current timezone database or trusted calendar conversion for each actual date.
2. Avoid scheduling a recovery or bulk restart around an ambiguous local clock boundary when a normal business-hour window is available.
3. Check capacity reset assumptions separately from the visible sending window.

Limits and next action

Do not change application timestamps manually to compensate for an unverified display issue. Record a concrete due-time example and involve the operator if the observed scheduler behavior differs from the intended named-timezone setting. A one-hour display difference is not enough evidence that a message was sent twice.

Source: Zintara sequence product context