Ads Insights API time_ranges validation not in account timezone

API Bugs
1

Issue

The Ads Insights API rejects a valid date_range when the ad account timezone is ahead of UTC.

Ad account timezone

Australia/Brisbane (UTC+10)

Request pattern

An hourly job retrieves recent Insights data so that late-arriving or backfilled metrics such as clicks and conversions can be reconciled.

The request always uses:

  • type: date_range
  • since: current date in the ad account timezone minus 10 days
  • until: current date in the ad account timezone

Both dates are normalized using the ad account timezone.

Actual behavior

After local midnight in Australia/Brisbane, requests fail for several hours with:

time_ranges.end cannot be in the future

The same request succeeds later in the morning without changing the requested local calendar date.

Expected behavior

Because until is equal to the current date in the ad account’s configured timezone, it should be accepted.

The validation of time_ranges.end should use the ad account timezone rather than UTC or another server-side timezone.

Likely cause?

The API appears to validate the date-only until value against a UTC/server-side current date.

For example, at:

2026-08-14 01:00 Australia/Brisbane

the account-local date is:

2026-08-14

while UTC is still:

2026-08-13

As a result, an until value of 2026-08-14 may incorrectly be classified as a future date.

Impact

Hourly reporting/reconciliation jobs cannot retrieve the current local day’s data during this window. This is particularly problematic for integrations that intentionally re-fetch recent dates to account for late-arriving clicks, conversions, or attribution changes.

Workaround

Temporarily clamp until to the current UTC date. This prevents the validation error but means the current ad-account-local day cannot be queried until UTC rolls over.

Useful diagnostic information to attach

  • Ad account ID: adacct_6a1d20d06cc0819692575392b1037799
  • Sample x-request-id :
    • At 2026-08-13T14:16:55.897043008Z (~00:16 local)L req_461b860871e041a8a3d9b3c69f9094b8
    • At 2026-08-13T15:16:55.881064248Z (~01:16 local): req_1e19a3bf814744ff932f79bbd1da76bc
    • At 2026-08-13T23:17:02.363827800Z(~09:17 local): req_a895597be0da4d2aa83f9cb696f3c44f
  • Ad account timezone is Australia/Brisbane

Any assistance in fixing this issue would be highly appreciated. Thanks.

Felipe

4

Hi @felipe.flores :waving_hand:

Thanks for reporting this!

We’ve confirmed that the Insights API is validating date_range end dates against UTC rather than your ad account’s timezone. For Australia/Brisbane, this can incorrectly reject the current local date between midnight and 10 a.m. AEST.

We’re working on a fix. Until then, setting until to the current UTC date avoids the error, though current-day data won’t be available until 10 a.m. AEST.

Thanks for including the request IDs and reproduction details - they helped us confirm the issue :raising_hands:

I’ll let you know once the fix is live :memo:

5

Thanks very much @siddhant . Looking forward for the fix!