stianbranden | 2017-04-05 12:51:05 UTC | #1
Hi
I'm trying to get conversation aggregates results in local time (UTC+1/+2). The result seems to ignore the timeZone settings as the result is always given in UTC-time (Z). I`ve tried giving timeZone as "Europe/Oslo", "Europe/Paris" or as "+01:00" also not yielding any difference in the result set. How ever if I enter something invalid as timeZone I get an error returned.
Se screenshot from Postman! <img src="//inin-prod-use1-developerforum.s3.amazonaws.com/original/1X/6424af771a70cdc8cc09598904374bf4b2ccc76a.png" width="524" height="500">
KR/ Stian
tim.smith | 2017-04-05 13:58:57 UTC | #2
It appears that the timeZone property isn't working as documented. I've opened AR-5190 to address the 500 errors when you send an invalid value (it should be a 400 and tell you what was wrong) and AR-5191 to address the fact that accepted values don't work.
You can simply provide the timezone in the interval instead of using the timeZone property, which it looks like you're already doing in the request. The response is coming back in UTC, but it's been correctly converted from the timezone specified in your original interval. 2017-03-13T00:00:00.000+02:00 has been converted to 2017-03-12T22:00:00.000Z, which both represent the same moment in time. You'll probably want to convert that UTC timestamp to local time if you're using it as a display value.
tim.smith | 2017-04-05 14:59:00 UTC | #3
Update: The timeZone property actually does work as intended, but the documentation is pretty misleading. The property does not apply a timezone to the interval. The purpose of the property is to provide the time zone context when an interval spans a DST boundary. An example might look like this:
"interval": "2017-03-11T00:00:00.000-0500/2017-03-13T00:00:00.000-0400",
"timeZone": "America/Indiana/Indianapolis"
Because the offsets are different on either side of the DST boundary, more information is needed to properly interpret the interval. Providing the timeZone property allows the date time library to know that there was a DST change during this interval and can pull the correct data.
system | 2017-08-28 19:33:37 UTC | #4
This post was migrated from the old Developer Forum.
ref: 1147