ConvertKit’s broadcast scheduler lets you pick a send time in your local timezone. But the platform stores that time as a UTC offset—and it doesn’t automatically adjust for daylight saving changes. If you schedule a 9am send in March and your region observes daylight saving in April, your broadcast will go out at 8am or 10am instead.
This isn’t a bug. It’s how the system handles timezone data. And if you’re running a daily or weekly broadcast, you won’t notice until your open rates drop or readers start asking why your send time shifted.
How ConvertKit stores scheduled send times
When you schedule a broadcast for 9:00am Eastern Time, ConvertKit doesn’t store “9am Eastern.” It converts that to a UTC offset—currently UTC-4 during daylight saving, UTC-5 during standard time—and locks in the absolute UTC timestamp.
If you schedule in winter (UTC-5) for a March send, that 9am broadcast is stored as 2pm UTC. When daylight saving kicks in and your local clock springs forward, your region is now UTC-4—but the broadcast still fires at 2pm UTC, which is now 10am local time.
The reverse happens in autumn. A broadcast scheduled during daylight saving will arrive an hour early once standard time resumes.
This affects any operator in a region that observes daylight saving: most of the US and Canada, parts of Europe, Australia, and a handful of other countries. If your timezone doesn’t shift, you won’t hit this issue.
When this actually breaks your workflow
One-off broadcasts are fine. You schedule, you send, you move on. The problem surfaces with recurring sends or templates you duplicate week after week.
If you run a Tuesday morning briefing and schedule it every Monday night for a 7am send, you’ll duplicate last week’s broadcast, update the content, and leave the time slot untouched. That works until the clocks change—then your 7am send becomes 6am or 8am, depending on direction.
Engagement suffers. A 6am send might hit inboxes before your audience wakes up, pushing your email down the stack. An 8am send competes with the morning rush and office distractions. Either way, open rates drop, and you won’t know why unless you check the actual delivery timestamp in your sent folder.
How to avoid the offset trap
The simplest fix: manually verify your send time after every daylight saving transition. Mark your calendar for the second Sunday in March and the first Sunday in November (US dates), and check every scheduled or recurring broadcast. If the time shifted, update it.
If you’re scheduling more than a week out, pick your send time on the day you’re actually sending—not in advance. That way, the UTC offset reflects the current timezone rules.
For operators running daily sends, consider switching to a relative schedule instead of an absolute one. ConvertKit doesn’t natively support “send X hours after signup” for broadcasts, but you can replicate the behaviour with a sequence: create a one-email sequence, set the delay to zero, and trigger it with a segment or tag. That way, the send time is always relative to subscriber activity, not a fixed UTC timestamp.
Another option: use a timezone that doesn’t observe daylight saving. If you schedule in UTC or Arizona time (which stays on Mountain Standard year-round), your send time never shifts. Your local reference changes, but the broadcast fires at a consistent absolute hour. This works if your audience is global or if you don’t care about hitting a specific local time—just a consistent daily slot.
What other platforms do differently
Some ESPs handle this better. MailerLite stores send times as a timezone identifier (like America/New_York) rather than a UTC offset, so the platform automatically adjusts for daylight saving. You schedule 9am Eastern, and it stays 9am Eastern year-round, regardless of offset changes.
Others, like Mailchimp, let you pick a subscriber’s local timezone for sends—so a 9am broadcast goes out at 9am in each recipient’s region. That’s useful for global lists, but it spreads your send window across 24 hours, which complicates analytics and real-time engagement tracking.
ConvertKit’s approach isn’t wrong—it’s just literal. The platform does exactly what you tell it: send at this UTC timestamp. If you want a different timestamp after the clocks change, you have to say so.
If timezone handling matters to your workflow—especially if you’re running daily sends or operating across multiple regions—test your platform’s behaviour before committing. Schedule a broadcast six months out, note the UTC offset, and check again after a daylight saving transition. If the local time shifted, you’ll need a manual or automated workaround.
Got a question about email tooling or workflow automation? Reply to this email—we cover reader questions every Sunday.