Ad scheduling across timezones and daylight saving

“Turn the campaign on at nine” is incomplete when your team, customers, and automation server use different clocks. Nine in the account’s timezone may be the middle of the afternoon for the people you want to reach.

A recurring schedule needs both a local time and the rules for the location that time belongs to. Make that decision before translating hours into a manual reminder or an automation job.

Choose whose working day the schedule follows

For a campaign supporting a staffed sales team, the team’s location may be the right reference. For a campaign aimed at business customers in a particular market, their local working day may matter more. Write the choice into the schedule’s name or operating notes so another person can interpret it.

Use a named timezone such as Europe/London or America/New_York. A fixed UTC offset only describes a difference from UTC; it does not express all the local clock-change rules a recurring schedule may need.

The IANA Time Zone Database maintains location-based time rules, including changes to offsets and daylight saving. These rules can change through government decisions, so software needs current timezone data rather than a conversion copied into a spreadsheet once.

Why a fixed-time manual workflow drifts

Suppose your intention is to start at 09:00 in London. Under current rules, London observes UTC in winter and UTC+1 in summer. A job fixed at 09:00 UTC therefore runs at 09:00 local time in winter and 10:00 local time in summer. The UK government explains the current clock-change rules.

Moving the job once is not enough if it must keep following the local clock. Someone must also maintain it through future transitions. A recurring rule expressed in Europe/London lets timezone-aware software calculate the appropriate instant for each date.

An automation tool may offer a timezone setting, but inspect where that setting applies. The schedule trigger, a timestamp sent to an API, and the reporting display may each use different rules. Test the resulting action time, not just the text shown in the editor.

A campaign’s dates are a separate control

OpenAI’s campaign API documents start and end timestamps, plus pause and activate actions. The documented fields do not describe a recurring local weekday window as of September 28, 2026. If your account does not offer that rule, a manual or external workflow has to maintain it. OpenAI campaign API reference.

Keep the campaign’s overall dates in mind when testing a recurring schedule. A requested activation does not remove an end date, fix a review issue, or replenish a budget. Investigate those conditions separately if the campaign does not deliver during the expected window.

Know what happens when the clock changes

Some local times do not exist when clocks move forward. Others occur twice when clocks move back. A schedule near that transition needs an explicit interpretation; otherwise two tools may produce different results from the same displayed time.

Campaign Hours uses the schedule’s named timezone. For a boundary inside a skipped period, it advances to the first valid local minute. For a repeated local time, it uses the earlier occurrence for a start and the later occurrence for an end. That means a window crossing a clock change can have a different elapsed duration from an ordinary day.

Most daytime business schedules avoid the ambiguous hours, but overnight operations should review them carefully. Check the upcoming actions when the clock-change date enters the preview, and confirm the executed action afterward in Activity.

Make overnight windows unambiguous

A window starting at 22:00 and ending at 02:00 crosses midnight. In Campaign Hours, selecting Monday for that window means it starts on Monday and finishes on Tuesday. The selected day refers to the start of the window.

This is easy to misread in a handoff. Describe it as “Monday 22:00 to Tuesday 02:00” when sharing the plan. Check weekend boundaries too: a Friday evening window can continue into Saturday even if Saturday is not selected as a start day.

Separate schedule time from display time

Campaign Hours stores a timezone on each schedule. The workspace’s display timezone is used in Activity; changing that setting does not rewrite existing schedule timezones. When comparing an action with a run window, first make sure you are reading both in the same timezone.

For several markets, use distinct schedules and appropriate campaign groups when local working hours differ. One shared UTC window cannot represent the same local business hours everywhere throughout the year.

Before enabling, review the selected days, overnight boundaries, timezone, and upcoming actions together. Afterward, check verified results rather than assuming that a successful trigger proves the remote campaign changed. Our hourly scheduling walkthrough covers that complete flow.