Timezone and scheduling

Timezone determines what time zone scheduled runs are calculated relative to. It's critical for distributed teams and for data sources in different time zones.

How timezone affects the schedule

Calculating the run time

The run time is always interpreted in the specified timezone. If it's set to "08:00 MSK (UTC+3)," the run happens:

• At 08:00 Moscow time
• At 05:00 London time (UTC+0)
• At 21:00 the previous day in Los Angeles (UTC-8)

Daylight saving time transitions

The system automatically accounts for daylight saving transitions if the timezone observes them:

• Spring forward: on the transition day, the time shifts. If a run was set for 02:30, and clocks jump from 02:00 to 03:00, the run will be skipped (02:30 doesn't exist). The system logs it as Missed and catches it up if catch-up is enabled
• Fall back: 02:30 occurs twice. The system runs the report once (the first of the two occurrences)

The data source's timezone

The data source's timezone affects what counts as "today," "yesterday," or "this month":

• Google Ads uses the ad account's timezone
• Facebook Ads uses UTC-8 (Pacific Time)

This means yesterday at 03:00 MSK for Facebook Ads is still "today" in Pacific time (UTC-8), and "yesterday's" data may be incomplete.

Step-by-step instructions

1. Choose a timezone

In the schedule settings, choose a timezone from the dropdown. All standard IANA timezones are available (Europe/Moscow, America/New_York, Asia/Tokyo, etc.).

2. Reconcile it with the data source's timezone

Account for the difference between the schedule's timezone and the source's timezone:

• If the source is in UTC-8 and the schedule is in UTC+3, the difference is 11 hours
• yesterday in UTC+3 begins 11 hours earlier than in UTC-8
• It's recommended to set the run time later, to account for this difference

3. Account for your team

For distributed teams, choose a timezone convenient for most people: typically the head office's timezone, or UTC+0 as a neutral choice.

4. Verify in practice

After configuring it, wait for the first automatic run and check: does the actual run time match what you expected, is the data accurate given the timezone difference, and are there no missed runs due to a time mismatch.

How to verify

• Check the actual execution time in the run history
• Compare it to the expected time in your local timezone
• After changing the timezone, verify that the next run time recalculated correctly
• On a daylight saving transition day, verify that the run wasn't missed

Recommendations

• For sources on UTC-8 (Facebook Ads), set the run time no earlier than 12:00 UTC+3 — yesterday's data is guaranteed to be ready
• Use yesterday rather than today together with a schedule — the data is more stable
• For critical reports, build in a 2-3 hour buffer after the previous day ends in the source's timezone

Related articles

• Daily — configuring the run time
• Weekly — days of the week and timezone
• Missed runs — Missed due to DST
• Date range — how timezone affects yesterday/today