Hi,
I'm using a webservice that returns me data that takes into account my local timezone (all their data is expressed in UTC, and they return me data adjusted to my timezone, so 2014-12-31T22:00:00.000Z for instance.
I'm using the "date" type for the category axis, but realized something strange, that depends on the actual interval (year, month, day...). It appears that for UTC dates, Kendo DataViz converts them to local dates. For instance, if I received hourly data, Kendo DataViz automatically shows them using an hourly format, and if I receive 2014-01-02T22:00:00.000Z, it's rendered as midnight on 03rd of january (I'm leaving in UTC+2). However, when dates are shown in monthly or yearly interval, it seems Kendo DataViz omits completely the conversion, so 2013-12-31T22:00:00.000Z is shown as 2013 year instead of 2014 (which is supposed to be the expected result in UTC+2).
Here is a simple gist that reproduces the issue: http://jsbin.com/mapif/4/
As you can see, the first graph that shows data on yearly basis, conversion is not done, while it's done in the other chart that shows data on hourly basis.
Thanks!
I'm using a webservice that returns me data that takes into account my local timezone (all their data is expressed in UTC, and they return me data adjusted to my timezone, so 2014-12-31T22:00:00.000Z for instance.
I'm using the "date" type for the category axis, but realized something strange, that depends on the actual interval (year, month, day...). It appears that for UTC dates, Kendo DataViz converts them to local dates. For instance, if I received hourly data, Kendo DataViz automatically shows them using an hourly format, and if I receive 2014-01-02T22:00:00.000Z, it's rendered as midnight on 03rd of january (I'm leaving in UTC+2). However, when dates are shown in monthly or yearly interval, it seems Kendo DataViz omits completely the conversion, so 2013-12-31T22:00:00.000Z is shown as 2013 year instead of 2014 (which is supposed to be the expected result in UTC+2).
Here is a simple gist that reproduces the issue: http://jsbin.com/mapif/4/
As you can see, the first graph that shows data on yearly basis, conversion is not done, while it's done in the other chart that shows data on hourly basis.
Thanks!
4 Answers, 1 is accepted
0
Michaël
Top achievements
Rank 1
Rank 1
answered on 03 Apr 2014, 07:40 PM
EDIT: it may not seem obviosu depending on your timezone, so I attached a screen to show you how it looks here (UTC+2)
0
Hi,
The discrepancies you see is most likely due to DST changes. Your current offset is GMT+2, but dates before the DST transition get a GMT+1 offset.
Thus the behavior that can be seen in the screenshot is normal. The dates in the first graph gets interpreted as "2012-12-31T23:00" and "2013-12-31T23:00".
My recommendation is to stick to client dates without Z suffix. These won't be changed by the browser in any way, regardless of time zone.
Stable behavior with UTC dates requires full time zone information. We can help if this is actually a requirement, but you can probably get away with client dates.
I hope this helps.
Regards,
T. Tsonev
Telerik
The discrepancies you see is most likely due to DST changes. Your current offset is GMT+2, but dates before the DST transition get a GMT+1 offset.
Thus the behavior that can be seen in the screenshot is normal. The dates in the first graph gets interpreted as "2012-12-31T23:00" and "2013-12-31T23:00".
My recommendation is to stick to client dates without Z suffix. These won't be changed by the browser in any way, regardless of time zone.
Stable behavior with UTC dates requires full time zone information. We can help if this is actually a requirement, but you can probably get away with client dates.
I hope this helps.
Regards,
T. Tsonev
Telerik
Check out the Telerik Platform - the only platform that combines a rich set of UI tools with powerful cloud services to develop web, hybrid and native mobile apps.
0
Michaël
Top achievements
Rank 1
Rank 1
answered on 07 Apr 2014, 12:43 PM
I'm not sure to understand. Are you actually saying that the problem comes to the fact that my country have two different timezones depending on the period of the year?
The thing is that the service I'm using returns all the dates in UTC (with the Z suffix). I could eventually hack it and remove the Z from all the dates, but that's a bit of hassle.
To have localized data based on the client's timezone, should I ask my third party API data in UTC always, and let Kendo handle the conversion? It's not clear to me, basically I have four choices:
* I ask the web service to shift the dates according to my timezone, so if something is registered at 2013-12-13:T20:00, it will return 2013-12-13T:18:00Z (GMT+2).
* I ask the web service to shift the dates AND I remove the Z from all the dates.
* I ask the web service to NOT shift dates and keep the Z.
* I ask the web service to shift and dates and I DON'T keep the Z.
I think I've tried all 4, and none gave me the good results.
Regarding my example, I can't see how the screenshot is normal. Here in France we changed from UTC+1 to UTC+2 in 1st of April. So ALL the dates from the examples are indeed in UTC+1. I can't undertsandt why there is a discrepancy in the way Kendo show them. That does not make sense to me :(.
The thing is that the service I'm using returns all the dates in UTC (with the Z suffix). I could eventually hack it and remove the Z from all the dates, but that's a bit of hassle.
To have localized data based on the client's timezone, should I ask my third party API data in UTC always, and let Kendo handle the conversion? It's not clear to me, basically I have four choices:
* I ask the web service to shift the dates according to my timezone, so if something is registered at 2013-12-13:T20:00, it will return 2013-12-13T:18:00Z (GMT+2).
* I ask the web service to shift the dates AND I remove the Z from all the dates.
* I ask the web service to NOT shift dates and keep the Z.
* I ask the web service to shift and dates and I DON'T keep the Z.
I think I've tried all 4, and none gave me the good results.
Regarding my example, I can't see how the screenshot is normal. Here in France we changed from UTC+1 to UTC+2 in 1st of April. So ALL the dates from the examples are indeed in UTC+1. I can't undertsandt why there is a discrepancy in the way Kendo show them. That does not make sense to me :(.
0
Hi,
I think that the issue is caused by incorrect conversion of dates occurring before the DST transition. Their offset is -1, but the service subtracts the current offset (-2) resulting in incorrect UTC date.
The browser takes the resulting date and adds the offset it deems correct (+1) for its time zone. This is where the chart takes on, but the date is already off by 1 hour.
The problem you see in the screenshot is caused exactly by this. The dates appear to by one year off because 2012-12-31T22:00 + 01:00 is still 2012.
The web service should not shift dates and should remove the Z suffix. This will guarantee you that the chart will look the same regardless of browser time zone.
If this is not the desired result then the service should be corrected to return correct UTC dates.
Regards,
T. Tsonev
Telerik
I think that the issue is caused by incorrect conversion of dates occurring before the DST transition. Their offset is -1, but the service subtracts the current offset (-2) resulting in incorrect UTC date.
The browser takes the resulting date and adds the offset it deems correct (+1) for its time zone. This is where the chart takes on, but the date is already off by 1 hour.
The problem you see in the screenshot is caused exactly by this. The dates appear to by one year off because 2012-12-31T22:00 + 01:00 is still 2012.
The web service should not shift dates and should remove the Z suffix. This will guarantee you that the chart will look the same regardless of browser time zone.
If this is not the desired result then the service should be corrected to return correct UTC dates.
Regards,
T. Tsonev
Telerik
Check out the Telerik Platform - the only platform that combines a rich set of UI tools with powerful cloud services to develop web, hybrid and native mobile apps.