daylight saving change shifted the agent's scheduled sends an hour early - leads got woken-up emails for a week...

TL;DR

Daylight saving breaks any schedule stored as a fixed UTC offset. Store the intended local wall-clock time plus the IANA timezone name, let the timezone library compute the UTC instant at send time, and re-render the upcoming queue the day after each DST transition. The hour-early week happened because UTC instants computed before the change were never recomputed after it.

daylight saving change shifted the agent's scheduled sends an hour early - leads got woken-up emails for a week before anyone noticed

Steps

1. Confirm the skew: compare scheduled send times against actual delivery times for the affected week. A consistent one-hour offset starting on the DST transition date is the signature.

Expected: the offset starts exactly on the transition day, not gradually.

1. Change the storage model: keep the intended local time (e.g. 9:00am) and the IANA timezone name (e.g. America/Chicago) as the source of truth. Compute the UTC instant lazily at send time through the timezone library.

Expected: the library absorbs the DST shift automatically on every send.

1. For already-queued sends, run a one-time re-render: recompute every future UTC instant from the stored local time and zone, and update the queue. Do this the day after each spring and fall transition as a standing job.

Expected: the queue matches wall-clock intent again after the transition.

1. Add a skew monitor: after each send, compare the actual local delivery hour against the intended local hour. Alert if the median skew across a day exceeds 15 minutes.

Expected: the next DST bug pages someone within a day, not a week.

1. Audit the damage window: list every send that landed outside the overnight guardrail during the skewed week, and note the accounts for the rep to acknowledge if any lead complained.

Expected: a bounded list of affected sends, not an open-ended worry.

Use this when

• Sends shifted by exactly one hour around a DST transition
• The skew started on the spring-forward or fall-back date
• Schedules were computed as fixed UTC instants ahead of time

Not for this skill when

• Sends land at random wrong hours (missing timezone conversion instead)
• The wrong zone was selected entirely, e.g. rep zone vs lead zone (wrong-zone bug)
• The schedule used the server clock with no zone at all (server-clock bug)
• The one-hour shift is constant year-round (a fixed offset error, not DST)

Variant phrasings

• "sends went out an hour early after daylight saving started"
• "DST transition shifted scheduled emails by one hour"
• "fall-back clock change made follow-ups land an hour late"

Why it happens

A UTC instant is absolute; a wall-clock time is not. The scheduler computed "9am Chicago time" as a UTC instant before the transition, then the offset changed by an hour and every precomputed instant was suddenly an hour off. Storing the instant instead of the intent froze the old offset in place. Computing the instant at send time from the zone name lets the DST database do its job.

Edge cases

• The transition weekend itself: 2am to 3am does not exist in spring. Sends scheduled in the missing hour should roll forward to 3am, never silently drop.
• Southern-hemisphere leads transition on opposite dates. Per-lead zone names handle this; a global "DST happened" flag does not.
• Arizona, Hawaii, and parts of Indiana do not observe DST. Their zones encode this correctly, which is exactly why zone names beat manual offset math.
• Historical schedule audits must use the timezone database version from the send date. Re-rendering old sends with the current database can show phantom skews.

Provenance

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