Calling someone at the wrong hour is both rude and, in many places, against the rules. Permitted calling windows are usually defined in the prospect's local time, which sounds simple until your list spans several timezones and your reps are dialling from one. Get it wrong and a nine in the morning call for you lands at six in the morning for them. This guide covers why calling hours are anchored to the contact's timezone, why using that timezone (not the rep's) is what keeps you inside the window, and how a pre-dial gate enforces it without unfairly blocking contacts whose timezone you simply do not know.
Why calling hours are set by the contact's local time
Permitted-time rules exist to protect the person being called from calls at unreasonable hours, so they are naturally defined from that person's point of view: a window in their local time, typically bounded by an earliest and latest hour. The exact window, and whether it differs by day or by the kind of call, varies by jurisdiction, so treat the specific hours as a question for your own compliance team rather than a fixed number.
The principle, though, is stable everywhere: the clock that matters is the prospect's, not the rep's. That single fact is what makes calling-hours compliance a timezone problem rather than a simple business-hours setting.
Why the rep's timezone is the wrong clock
If a dialler uses the rep's local time, a distributed list quietly breaks compliance. A rep dialling at nine in the morning their time is calling five hours ahead into the early hours for a prospect further east, or well before opening for one further west. The rep is not doing anything obviously wrong; the tool is measuring against the wrong clock.
Anchoring the window to the contact's timezone fixes this. Each dial is judged by what time it is for the person being called, so the same session can run down a multi-timezone list and only place each call when it is inside that contact's permitted window. In a fast HubSpot power dialler session, where the tool advances from one prospect to the next on its own, this has to be automatic; nobody can eyeball timezones at dialling speed.
How a pre-dial gate enforces the window
A pre-dial gate resolves the contact's timezone, works out the current local time for that contact, and checks it against the permitted window before the call is placed. If the contact is outside the window the dial is blocked and the session moves on to the next prospect, exactly as it does for a do-not-call match.
A contact with no reliable timezone is a data gap, not a violation. Blocking every such contact would quietly hide large parts of a list and punish reps for missing CRM data. Ringside's rule is that an unknown timezone never blocks the dial: the call is allowed to proceed, and improving the underlying data is a separate, better fix than a blanket block.
- Judged by the contact's clock. The window is evaluated in the prospect's local time, not the rep's.
- Blocked before connect. A dial outside the window is stopped before it rings and the session advances.
- Unknown timezone passes. A missing or unresolved timezone is treated as a data gap and never blocks the call.
- Logged either way. Every attempt, allowed or blocked, is written to an audit log.
Calling hours are one half of Ringside's pre-dial compliance gate; do-not-call is the other. See DNC compliance for outbound for the do-not-call side, and the HubSpot power dialler guide for how both fit into the dialling flow.
Ringside checks each contact's local calling hours before the dial, so a multi-timezone list stays inside the window without anyone doing the maths.
Get startedFrequently asked questions
Should calling hours be based on my timezone or the prospect's?
The prospect's. Permitted-time rules are defined in the local time of the person being called, so a dialler should judge each call by the contact's timezone, not the rep's. Ringside evaluates the window in the contact's local time before every dial.
What happens if a contact's timezone is unknown?
With Ringside, an unknown timezone never blocks the call. A missing timezone is a data gap rather than a violation, so the dial is allowed to proceed and improving the CRM data is handled separately rather than by blocking the contact.
Does the dialler stop if a contact is outside calling hours?
It stops that specific dial, not the session. A contact outside the permitted window is blocked before the call connects, the attempt is logged, and the dialler moves on to the next prospect.