Scheduled sends around a daylight-saving time change used to shift or, in some cases, duplicate. That's fixed: your send times now stay correct through the transition.
What changed
When clocks moved for daylight saving, some scheduled sends were affected by the hour shift. An email scheduled for a specific time relative to your account's timezone could go out at the wrong actual time once the clocks changed, effectively an hour early or an hour late compared to what you'd set. In rarer cases, a send scheduled right around the transition window could be duplicated, going out twice instead of once. This came from how the scheduler handled the hour shift internally, not from anything wrong in your campaign settings or send schedule.
The scheduler now handles daylight-saving transitions correctly. Sends scheduled for a specific time keep that time relative to your account's timezone through the change, so a send you scheduled for 9am stays a 9am send whether it falls before or after the clocks move. The condition that could cause a duplicate send around the transition window is gone as well.
How to use it
There's nothing to do. This is a fix inside the scheduler itself, and it applies automatically to any send scheduled across a daylight-saving transition going forward. If you already have sends scheduled that span a transition date, they'll go out at the correct local time without you needing to re-schedule anything.
If you want to confirm this for yourself, check a campaign with sends scheduled near a known daylight-saving date in your region and compare the actual send times against what you originally set. They should match, both before and after the transition.
Why it matters
A send that goes out an hour off, or twice, undermines timing you set up on purpose. Maybe you scheduled a send for a specific time of day because you know when your prospects tend to check email, or you spaced out a sequence deliberately to avoid looking automated, or you're offering a meeting slot where the actual delivery time matters to the message itself. A shifted or duplicated send breaks that intent without you doing anything wrong, which makes it a particularly frustrating kind of bug: your settings were correct, but the outcome didn't match them.
Getting this right through every clock change means your schedule means what you set it to mean, consistently, whether or not there happens to be a daylight-saving transition in the middle of your campaign. You shouldn't have to remember to double-check your sends twice a year around a clock change; the scheduler should just handle it.
The duplicate-send version of the bug was the more serious of the two. A shifted send time is a timing annoyance; a duplicated send means a prospect gets the same email twice, which reads as sloppy at best and can look like a technical problem with your outreach at worst, undermining exactly the impression a carefully written cold email is trying to create. Both issues traced to the same underlying handling of the hour shift, and both are addressed by the same fix.
Scheduling across an upcoming transition
If a prospect ever mentioned receiving a duplicate email around a clock change in the past, you now have an explanation, and it's not something you need to guard against going forward. There's no setting related to daylight saving to check or adjust; the scheduler accounts for it automatically based on the timezone already set on your account.
If your team schedules campaigns well in advance, including sends that land on the other side of an upcoming daylight-saving date, you don't need to build in any manual workaround, like avoiding scheduling across the transition window. Schedule normally, and trust that the send time you set is the send time that goes out.
Why this edge case is worth getting right
Timing is one of the few levers you have real control over in cold outreach, since you can't control whether a prospect opens an email, but you can control when it lands in their inbox. A bug that silently shifts or duplicates sends specifically around a twice-a-year event is easy to miss as a pattern, since most people don't think to check their send logs against a daylight-saving date unless something already seemed off. Fixing it at the source means you don't have to think about it at all.
This kind of bug also tends to erode confidence disproportionately to how often it actually occurs. It only surfaces twice a year at most, but each time it does, it calls into question whether the schedule you set is being honored the rest of the time too. A scheduler that gets this specific, infrequent edge case right is one more reason to trust that the more common cases, a send scheduled for next Tuesday at 10am with no clock change anywhere nearby, are being handled correctly as well.
If your account operates across multiple regions with contacts or team members in different timezones, this fix applies per account timezone rather than depending on where any individual contact happens to be. The correction is in how the scheduler itself interprets and applies your account's clock, which is the same logic used regardless of how many timezones your outreach actually touches.
There's no migration or backfill needed on your part for sends that already went out incorrectly during a past transition; this fix is forward-looking, correcting how future transitions are handled rather than retroactively adjusting anything that already sent. The next daylight-saving transition your account passes through is the one you'll see this behave correctly on, with no separate confirmation needed on your end beyond checking your own send log if you want the reassurance. From here forward, a scheduled send stays anchored to the time you set for it, permanently, regardless of how many clock changes pass between when you schedule it and when it actually goes out.
Availability
This applies to all scheduled sends, in any account timezone that observes daylight saving.