Daylight Saving Time Ends November 1: Check Every Client's Send Windows First
On Sunday, November 1, 2026, most of the United States turns its clocks back an hour at 2:00 a.m. local time. For one person, that is an extra hour of sleep. For an agency running outbound across several client workspaces, it is a quiet way for send windows to drift, for Monday morning emails to land an hour early, and for one state's prospects to suddenly sit in a different relationship to the others.
Nothing breaks loudly. That is the problem. Here is what changes, where agencies usually get caught, and a short check to run in the last week of October.
What actually changes
Per timeanddate.com and USA Today's 2026 coverage, daylight saving time ends at 2:00 a.m. local time on Sunday, November 1, when clocks move back to 1:00 a.m.
Not everyone moves:
- Hawaii stays on standard time all year.
- Most of Arizona stays on standard time all year. The Navajo Nation, which extends into New Mexico and Utah, does observe daylight saving time. The Hopi Nation, inside the Navajo Nation, follows Arizona's no-DST rule.
- US territories including Puerto Rico, Guam, the US Virgin Islands, American Samoa, and the Northern Mariana Islands do not change clocks.
The Arizona detail matters more than it seems. From March to November, Phoenix lines up with Los Angeles. After November 1, Phoenix lines up with Denver, one hour ahead of Los Angeles. A campaign that grouped Arizona with the Pacific coast for the summer now sends to Arizona an hour off.
Where agencies get caught
1. Windows stored as a fixed UTC offset. If a send window was saved as "13:00 to 21:00 UTC" to mean 9 a.m. to 5 p.m. Eastern during daylight time, it becomes 8 a.m. to 4 p.m. Eastern after November 1. The fix is to store windows in a named time zone such as America/New_York or America/Phoenix, not as an offset. Named zones carry the daylight saving rules with them.
2. Prospect time zones guessed from the state. "Arizona = Mountain time" is only true in winter. In summer, most of Arizona matches Pacific time, while the Navajo Nation follows Mountain daylight time. "Indiana = Eastern" misses the counties on Central time. If prospect time zones were inferred from state names, spot-check the ones on the edges.
3. The client's own business hours. Your client's sales team keeps working its usual local hours. If AE handoffs, booking links, or a first-human-touch SLA are measured in UTC, the reporting shifts by an hour too.
4. Weekend queues. The change happens early Sunday. Anything a scheduler queued over the weekend for "Monday 8 a.m." was computed before the change. Check that queued items recompute against local time rather than holding a timestamp calculated on Friday.
5. Reports that compare weeks. A "best hour to send" chart that spans the change will show a one-hour shift that is just the clock. Note the change date on any client report that covers the week of November 2.
A five-minute check per client
Run this in the last week of October for every active client workspace:
- List every send window and confirm it is stored as a named zone, not an offset.
- Pull prospects in Arizona, Hawaii, and US territories and confirm their time zone field is set to the right named zone (America/Phoenix, Pacific/Honolulu, and so on).
- Check what is queued for Monday, November 2. Confirm the first sends land inside the window in the prospect's local time.
- Check booking links and calendars. Make sure the client's calendar tool uses their local zone, so an "available 9 to 5" slot does not move.
- Write the change into the weekly client report so the client does not read a one-hour shift as a performance change.
We have argued before that agencies should be able to prove send-window compliance across client time zones. The DST change is the week that proof gets tested.
And in March
Daylight saving time starts again on the second Sunday in March. The same check applies in reverse. Put it on the calendar now, for every client, while you are thinking about it.
Where GTM fits
GTM sends through each client's connected domains with send windows and limits, inside an isolated workspace for each client. Whatever tool you use, the rule is the same: store windows and prospect locations in named time zones, and check the queue the Friday before the clocks change.
If you run outbound for several clients and want send windows you do not have to babysit, join the waitlist.
Sources
- timeanddate.com, "USA and Canada End Daylight Saving 2026": https://www.timeanddate.com/news/time/usa-canada-end-dst-2026.html
- timeanddate.com, "Daylight Saving Time 2026 in Arizona": https://www.timeanddate.com/time/change/usa/arizona?year=2026
- timeanddate.com, "Daylight Saving Time 2026 in the United States": https://www.timeanddate.com/time/change/usa
- USA Today, "Clocks expected to change" (July 31, 2026): https://www.usatoday.com/story/news/nation/2026/07/31/daylight-saving-time-end-clock-fall-back-2026/91109892007/
- IANA Time Zone Database: https://www.iana.org/time-zones