This is a migrated thread and some comments may be shown as answers.

UTC conversion bug ?

4 Answers 51 Views
Charts
This is a migrated thread and some comments may be shown as answers.
Michaël
Top achievements
Rank 1
Michaël asked on 03 Apr 2014, 07:37 PM
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!

4 Answers, 1 is accepted

Sort by
0
Michaël
Top achievements
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
T. Tsonev
Telerik team
answered on 07 Apr 2014, 11:12 AM
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
 

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
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 :(.
0
T. Tsonev
Telerik team
answered on 08 Apr 2014, 08:40 AM
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
 

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.

 
Tags
Charts
Asked by
Michaël
Top achievements
Rank 1
Answers by
Michaël
Top achievements
Rank 1
T. Tsonev
Telerik team
Share this question
or