dsouther | 2016-08-09 18:39:35 UTC | #1
I'm running into an issue with aggregating data on a daily or weekly basis where the data is grouped based on UTC time. I have setup all my queries to convert from local time to UTC, e.g. my timzone offset is -5, so I convert
2016-07-31T00:00:00/2016-08-07T00:00:00 to 2016-08-31T05:00:00/2016-08-07T05:00:00,
before I make the request, but when I aggregate, the first interval starts at 2016-08-31T00:00:00 in UTC, which in CDT is 7pm on July 30th.
It would be nice if when aggregating, it would use the left side of the interval as the starting point. Another possible solution would be if the interval parameter supported timezones (does it?).
tim.smith | 2016-08-09 19:38:28 UTC | #2
Can you post your full query body and the context id from the response? I am not able to reproduce this with this request:
POST /api/v2/analytics/conversations/aggregates/query HTTP/1.1 Host: api.mypurecloud.com Authorization: bearer xxxx Content-Type: application/json
{ "interval": "2016-08-08T01:00:00/2016-08-09T23:00:00" }
I get the following interval in the response:
<img src="//inin-prod-use1-developerforum.s3.amazonaws.com/original/1X/1810571774a1ed4f07643d3579a1cf29df17c622.png" width="620" height="238">
The interval must be specified in an ISO-8601 format, which supports time zone designators. If you want to specify timezones in EST, do it like this: 2016-07-31T00:00:00-05:00/2016-08-07T00:00:00-05:00.
dsouther | 2016-08-09 20:28:57 UTC | #3
I don't know why I was having issues with the timezone in the interval earlier, but it's working now; however, it didn't resolve my issue.
The problem is when I select a granularity, for example with
{ "interval": "2016-08-08T0:00:00-05:00/2016-08-09T23:00:00-05:00" }
I get
{ "results": [ { "group": { "mediaType": "voice" }, "data": [ { "interval": "2016-08-08T05:00:00.000Z/2016-08-10T05:00:00.000Z",
which is fine, but with
{ "interval": "2016-08-08T00:00:00-05:00/2016-08-10T00:00:00-05:00", "granularity": "P1D" }
I get
{ "results": [ { "group": { "mediaType": "voice" }, "data": [ { "interval": "2016-08-08T00:00:00.000Z/2016-08-09T00:00:00.000Z", "metrics": [ {
which removes the timezone information, giving me intervals aggregated based on the start/end of a day in UTC.
The same happens if I use PT24H.
here is the ININ-Correlation-Id for the second request 9cc82715-fd0f-4b6c-affa-8131b94ddb0a
tim.smith | 2016-08-09 20:58:07 UTC | #4
Thanks for the info. I've reproduced the issue. I'll let you know what I come up with.
The cause doesn't seem to have anything to do with timezones. It seems to be when you have a interval that is longer than 1 of your granularity setting. So if you pull back data for an interval of 2 days and the granularity is 1 day, the resulting interval will be midnight to midnight. It seems that a workaround is to specify an interval that is the same length of 1 granularity value.
tim.smith | 2016-08-09 21:16:22 UTC | #5
The issue has been identified and fixed. It should make it to production in the next day or two.
dsouther | 2016-08-09 21:59:07 UTC | #6
That's great, thanks!
system | 2017-08-28 19:26:17 UTC | #7
This post was migrated from the old Developer Forum.
ref: 274