TIME_INVALID_WINDOW for correct start date?

[hitamar]

Hi,

I encountered a problem while attempting to obtain campaign statistics via the “stats/accounts/:account_id/campaigns/:id” endpoint.

The problem is that I got an INVALID_TIME_WINDOW error with the following message: Expected start_time to be precisely aligned at midnight in timezone Africa/Cairo for granularity Some(DAY), got “2015-08-03T22:00:00Z”

But this is precisely midnight in Cairo, so what is the problem?
I tried this both with an exact time and with just a date, with the same result.

Thanks,
Itamar

[andrs]

@hitamar have a look at our documentation regarding Timezones - especially pay attention to this bit:

When using the /stats/ endpoints with granularity of DAY or TOTAL, the start_time value must be specified at midnight of the desired day in the local timezone of the account holder.

[hitamar]

Hi @andrs, thanks for the reply!
I read the documentation, the problem however is that 22:00 on August 3rd 2015 in UTC was midnight in Cairo, so what am I missing?

[andrs]

Hey @hitamar - is there any chance you could provide us with a twurl request that reproduces this error? This should make it a lot easier to debug. Also, I am assuming the accounts timezone is set to Cairo?

[controledash]

I am getting the same problem and it looks like a bug.
I am getting the timezone dynamically through my clients account and asking the daily report using the transformed date.

It works for
Europe/London
It works for
America/Sao_Paulo
BUT,
Strangely enough, I have another campaign with
America/Sao_Paulo
And I am getting the error.

Below are the parameters I am using. Both at the same account, so the same America/Sao_Paulo timezone.
While the first works, the second gives me:
Expected start_time to be precisely aligned at midnight in timezone America/Sao_Paulo for granularity Some(DAY), got “2015-05-22T02:00:00Z”

//this works
    [params] => stdClass Object
                    (
                        [start_time] => 2014-12-31T02:00:00Z
                        [end_time] => 2014-12-31T23:59:59Z
                        [account_id] => qfd7iv
                        [granularity] => DAY
                        [campaign_id] => 1y3wn
                    )

//this does not work. strangely, [campaign_id] is not returned when an error occur ( '1jvb5' on this call )
    [params] => stdClass Object
                    (
                        [start_time] => 2015-05-22T02:00:00Z
                        [end_time] => 2015-05-22T23:59:59Z
                        [granularity] => DAY
                        [account_id] => qfd7iv
                    )

I have a feeling that campaigns created on Energy Saving time will fail to match when we are evaluating the timezone programatically on a non Energy Saving time. And vice versa. I am saying this because right now in Brazil we are 2 hours difference from London. We are in Energy Saving time.

[controledash]

One more thing that makes me guess more about the Timezone problem:

On the campaigns where the problem happens, if I manually change the time to put one hour in advance (like in Energy Saving time) it works.

A possible bug?

[controledash]

I am trying to call through twurl:

twurl -t -H ads-api.twitter.com /0/stats/accounts/qfd7iv/campaigns/1jvb5?granularity=DAY&start_time=2015-05-22T00:00:00-0200&end_time=2015-05-22T23:59:59Z`

But I am facing a problem described om my comment here:

Sending GET parameters via twurl

Hello everyone, I trying to send request via twurl that contain additional GET parameters and always getting error "no matches found" - dont even send request to twitter api. Example: twurl /1.1/statuses/user_timeline.json?count=20 Response: no matches found: /1.1/statuses/user_timeline.xml?count=20 Example: twurl /1.1/statuses/user_timeline.json response is valid...

[controledash]

Ok, these are the TWURL calls showing exactly the problem.
Same account, same timezone, same midnight adjustment. One works, the other fails.

//this works
twurl -t -H ads-api.twitter.com '/0/stats/accounts/qfd7iv/campaigns/2hzvt?granularity=DAY&start_time=2014-12-31T00:00:00-0200&end_time=2014-12-31T23:59:59Z' | python -m json.tool

//this gives me TIME_INVALID_WINDOW
twurl -t -H ads-api.twitter.com '/0/stats/accounts/qfd7iv/campaigns/2hzvt?granularity=DAY&start_time=2015-05-22T00:00:00-0200&end_time=2015-05-22T23:59:59Z' | python -m json.tool

Strangely enough, I just realized I used by mistake the EXACT same campaign to call. And the first call works! This is definitely a bug.

[andrs]

Thanks for digging into this!

This does indeed look like a bug and matches a similar report we have seen in the past few days. Unfortunately this is not a trivial bug to fix, due to how our systems function internally, however we do have a solution in mind.

[controledash]

Tks @andrs!
Any idea about how much time it will take to solve?

[andrs]

We can’t commit to a timeframe unfortunately, but hopefully it won’t be too long! In the meantime, do use your workaround of changing the time as you outlined previously and keep an eye on this thread for whenever we’ve figured this out so you don’t need to use a workaround anymore

[controledash]

great! Tks!

[kenniy]

Hello @andrs. This issue seems to still exist. Only occur when there is no data at all for the queried time window. Is there any update on the bug fix? Thanks

[JBabichJapan]

Hi,

Because of the v0 deprecation we are no longer supporting queries related to v0. v1 the day alignment issues have changed significantly.

Could you please post a new thread explaining the problem with v1 endpoints per our posting guidelines (e.g. include twurl or bare minimum some specific request log that makes it clear what parameters you are using).

Thanks,

John

[JBabichJapan]