Expected start_time to be precisely aligned at midnight in timezone America\/Santiago for granularity Some(DAY), got \"2016-05-15T03:00:00Z\" for

[Asad]

Thanks @JBabichJapan ,@majoritasdev
thats right if send in both the hours 4 after 15 it sucess but, for this timezone i got the midnight hour is 3 ,
even if i try with the postman that there is no enetred hour it will failed after 15 ,
pictures attached ,

timezone before 15

timezone after 15

[JBabichJapan]

I’m not sure what’s going on when you leave the hours off but you should be able to send it in a combination of UTC-3 and UTC-4 for the case where the start time and end time ‘straddles’ the DST cut over (without error).

[majoritasdev]

Ok I realize this is a confusing one, but the way you have to call is like this:twurl -t -H ads-api.twitter.com ‘/1/stats/accounts/18ce53x6d8b?entity=ACCOUNT&start_time=2016-05-13T00:00:00-03:00Z&end_time=2016-05-15T00:00:00-04:00Z&granularity=DAY&metric_groups=BILLING&placement=ALL_ON_TWITTER’

@JBabichJapan: the Z in 2016-05-13T00:00:00-03:00Z is redundant - the timezone is already specified by -03:00, and Z is (fortunately) ignored (in PHP anyway). (fyi, @juanshishido)

@Asad: did it work for you like @JBabichJapan said? Because I had the impression that you already tried this variant and didn’t work.

[Asad]

Hi @majoritasdev,
yes it was long time ago and yes i tried like @JBabichJapan and it succesed , there another issue opended for chile when they changed again they timezone on 14/8 on chile 14/8

and also got workaround (i hope fix will be soon, i will not change the code spically for chile)
anyway that alot @majoritasdev for your answer.

Thanks,
Asaad

[majoritasdev]

You’re welcome. Glad to hear it succeeded!

[controledash]

Hello @JBabichJapan,
I am facing the exact same problem here and I am trying all the possible combinations of hours without hope.
My twurl giving me the “Expect time to be midnight in the account’s local timezone for day granularity” error:

twurl -H ads-api.twitter.com "/2/stats/accounts/18ce548xann?start_time=2017-10-08T00:00:00-03:00Z&end_time=2017-10-15T00:00:00-03:00Z&entity=CAMPAIGN&entity_ids=8t4m1&granularity=DAY&metric_groups=ENGAGEMENT&placement=ALL_ON_TWITTER" -X GET | python -m json.tool

Daylight saving in Brazil starts at the 15th, so calling

twurl -H ads-api.twitter.com "/2/stats/accounts/18ce548xann?start_time=2017-10-08T00:00:00-03:00Z&end_time=2017-10-14T00:00:00-03:00Z&entity=CAMPAIGN&entity_ids=8t4m1&granularity=DAY&metric_groups=ENGAGEMENT&placement=ALL_ON_TWITTER" -X GET | python -m json.tool

works fine.

I can handle this with code, but I need to some logics to follow. None of my trials are working to call reports ending on the 15th.

And there is one more WTF moment, if I call this report as an async one, it works.

twurl -H ads-api.twitter.com "/2/stats/jobs/accounts/18ce548xann?start_time=2017-10-08T00:00:00-03:00Z&end_time=2017-10-15T00:00:00-03:00Z&entity=CAMPAIGN&entity_ids=8t4m1&granularity=DAY&metric_groups=ENGAGEMENT&placement=ALL_ON_TWITTER" -X GET | python -m json.tool

And a big question, after all: why do we need to send timezone since it is forbidden to use a different timezone and twitter knows on its side the timezone of the account. I sincerely hope it gets fixed on next versions. (this is a more abroad question that maybe is out of the scope of this thread)

[controledash]

Well, it appears like there is a bug on Twitter side that it can´t handle the fact that THERE IS NO midnight when Daylight saving time (DST) starts.
This is how the clock goes:

..
2017-10-14 23:59:59.999998 UTC-03:00 (BRT)
2017-10-14 23:59:59.999999 UTC-03:00 (BRT)
2017-10-15 01:00:00.000000 UTC-02:00 (BRST)
2017-10-15 01:00:00.000001 UTC-02:00 (BRST)
...

So if I call with start date out of DST and end date after the beginning of DST with the proper clock changes it works fine:

twurl -H ads-api.twitter.com "/1/stats/accounts/18ce548xann?start_time=2017-10-14T00:00:00-03:00Z&end_time=2017-10-16T00:00:00-02:00Z&entity=CAMPAIGN&entity_ids=8t4m1&granularity=DAY&metric_groups=ENGAGEMENT&placement=ALL_ON_TWITTER" -X GET | python -m json.tool

But if I try to call end date or start date being the begging of DST (15 october in Brazil) it does not work at all and it seems impossible to call reports starting or ending at this day.

This should the correct call and the API should accept it:

twurl -H ads-api.twitter.com "/1/stats/accounts/18ce548xann?start_time=2017-10-15T01:00:00-02:00Z&end_time=2017-10-18T00:00:00-02:00Z&entity=CAMPAIGN&entity_ids=8t4m1&granularity=DAY&metric_groups=ENGAGEMENT&placement=ALL_ON_TWITTER" -X GET | python -m json.tool

Please let me know if this is an actual bug or if there is a proper way to handle this.

[controledash]

Also, this part of the documentation seems wrong:

https://developer.twitter.com/en/docs/ads/analytics/overview
"When dealing with granularity DAY, any end_time that is between start_time+00:00:01 to start_time+24:00:00 will return one day of stats. Any end_time that is between start_time+24:00:01 to start_time+48:00:00 will return two days of stats. And so on. Likewise for granularity HOUR, on a per-hour basis."

The api does not accept any hour different from midnight for end_time parameter.
Always returning:
"Expect time to be midnight in the account's local timezone for day granularity"

[juanshishido]

@controledash: This seems to be related to the way we check for midnight in the account’s local timezone. Please see this post for more information, which includes a possible workaround. Thanks!

[controledash]

Thanks @juanshishido
I believe you guys know that this is not a “solution” to the problem. This is a hack with some serious flaws.
Take a look on this:
First report giving the results from October 14, 2017 to October 16, 2017

twurl -H ads-api.twitter.com "/2/stats/accounts/18ce548xann?start_time=2017-10-14T00:00:00-03:00Z&end_time=2017-10-17T00:00:00-02:00Z&entity=CAMPAIGN&entity_ids=8t4n8&granularity=DAY&metric_groups=ENGAGEMENT,BILLING&placement=ALL_ON_TWITTER" -X GET | python -m json.tool

Results:

"billed_charge_local_micro": [
                            1947000000,
                            2036406914,
                            1869644744
                        ],

Second report, getting only the day of October 16, 2017

twurl -H ads-api.twitter.com "/2/stats/accounts/18ce548xann?start_time=2017-10-16T00:00:00-02:00Z&end_time=2017-10-17T00:00:00-02:00Z&entity=CAMPAIGN&entity_ids=8t4n8&granularity=DAY&metric_groups=ENGAGEMENT,BILLING&placement=ALL_ON_TWITTER" -X GET | python -m json.tool

Results:

"billed_charge_local_micro": [
                            1941000000
                        ],

So for the very same day, October 16, 2017, the api is giving different cost results:
R$1,869.64 on the first report
and
R$1,941.00 on the second.
A difference of 4%

Since we cannot control the data ranges our users will choose and we persist data, how can we be reliable?
And at end of the day, how much our client is actually paying?

Thanks a lot for the support!

[juanshishido]

@controledash: The workaround suggested in this post was not meant to be conveyed as a solution. It’s not. There seems to be an error when we check for midnight in the account’s local timezone when there is a time change.

In addition, as you’ve demonstrated, the billed_charge_local_micro values in the response to your first request—[1947000000, 2036406914, 1869644744]—do not align with what you see in your second request.

I’ve made the stats requests for campaign 8t4n8 with hourly-granularity and see the following spend numbers:

start time	end time	sum of billed_charge_local_micro
"2017-10-14T03:00:00Z"	"2017-10-15T03:00:00Z"	1947000000
"2017-10-15T03:00:00Z"	"2017-10-16T02:00:00Z"	1947000000*
"2017-10-16T02:00:00Z"	"2017-10-17T02:00:00Z"	1941000000

This matches the spend values on ads.twitter.com when I look at individual the dates.

However, when the date range is expanded to cover all three days, the numbers change.

We will take a closer look into what could be happening, but don’t have a time estimate.

Thanks.

---

* The array for this included only 23 values to account for the daylight savings time change.

[controledash]

Thank you so much @juanshishido!

[controledash]

Hey guys. Any news on that?
The problem is still there.

[juanshishido]

Thanks for the follow up, @controledash. We’re currently working to resolve other issues. This is currently in our backlog. Expect a few months before any additional news on this.

[controledash]

Thank you very much, @juanshishido.
It would be very helpful if you can ping this thread when you guys have a due date or the problem solved so I can update my clients.

Cheers from Brazil and keep the amazing work!

[controledash]

Hello @juanshishido,

We are approaching SummerTime here in Brazil again.
Can we trust that there will be a solution till there?

Tks

[juanshishido]

Thanks for the follow up, @controledash. No updates to report on this; it’s still in the backlog.

[pabloeemos]

Any news @juanshishido?
The problem got even worse now.
Brazilian´s DST time has changed recently to start on November 4th and Twitter is demanding now to receive end_time in DST right now. I believe Twitter is considering the start of Brazilian´s DST on October 20th.
This makes the API completely buggy to query results in present time.
Don´t you guys consider this extremely high priority?

[pabloeemos]

This picture from my profile shows how the whole Twitter platform is not adapted to the new Brazilian DST times. 30 of October is still NOT DST here. The time presented should be (GMT-03:00) Brasilia and not (GMT-02:00) Brasilia.

[Supermetrics]

Hi @juanshishido, I’d like to point out that the bug happens also with unspecified timezone, not only with clashing schemas. I understand that DST exceptions are a complicated issue, so do you possibly have plans on keeping your timezone schema up to date, with the help of some dedicated third party resource?