Kendo DateTimePicker Not Handling UTC Offset

Question

We are using the Kendo datetimepicker, implemented using the AngularJS directives:

<input type="text" kendo-date-time-picker k-ng-model="TheDateModel">

Where: TheDateModel = 2016-02-15 20:58:24.0000000 +00:00

I am in the CST timezone, which is -6 hour offset from the GMT. The current result of the datetimepicker shows a time of 8:58 pm but my expected result is 2:58 pm.

What in the world am I doing wrong?

Solution 1

Disclaimer: I work for Kendo UI team

The Kendo UI Datepicker uses JavaScript Date object internally to hold the selected date value. As you probably know, it always uses the local (browser) timezone. We tried to explain that caveat in our docs too:

• JavaScript Date Object - Basics

Due to this default behavior, the widget will use the already converted Date value (with the applied local timezone). The widget doesn't manipulate the value timezone, as it does not have sufficient information how to do that.

Solution

The best approach in this case is to convert the Date strings (like the one you mentioned "2016-02-15 20:58:24.0000000 +00:00") manually before feed the DatePicker widget. For instance, here is one possible approach to do that:

• http://dojo.telerik.com/EyuRA

Notice how the value is parsed and then adjusted in the loadData method. Similar thing should be done by the developer that needs to handle different TZ in their app.

Solution 2

I've been down this road and had to implement this:

http://www.telerik.com/support/code-library/using-utc-time-on-both-client-and-server-sides

Solution 3

So I found the solution to my problem. First off for clarity, and sorry for the misinformation, but my date was coming down from the server as 2016-02-15T20:58:24.0000000+00:00 - add the T and remove all spaces.

All that needed to be done was to add the k-parse-formats attribute to the directive as follows:

 <input type="text" kendo-date-time-picker k-parse-formats=['yyyy-MM-ddTHH:mm:sszzz'] k-ng-model="TheDateModel">

Boom, considers the offset and your current timezone, and correctly parses and displays the date and time. Just be aware, that when you specify your own parse formats, to include all possible formats that your dates could be.

For example, I then ran into a problem where I had milliseconds greater than 0 coming through on my dates: 2016-02-15T20:58:24.1234567+00:00. This broke the datetimepicker again. Simpler fix: just changed my parsing format to: yyyy-MM-ddTHH:mm:ss.fffffffzzz. Make sure the number of f is greater than or equal to the number of possible milliseconds.

<input type="text" kendo-date-time-picker k-parse-formats=['yyyy-MM-ddTHH:mm:ss.fffffffzzz'] k-ng-model="TheDateModel">

Comments

[Matt Johnson-Pint]

Unfortunately, the answer in that link violates "Time Zone != Offset". If the offset for the chosen date is different than the current offset (due to daylight saving time, for example), then the resulting time will be an hour off.

[Smiffy]

When the browser is in a timezone that has daylight saving this won't work for a short period each year. When the spring daylight saving occurs there is an hour that doesn't exist in local time because the clocks are moved forward 1 hour. For example if the browser timezone is Australia/Sydney try plugging in a time between 2017-10-01 02:00 and 03:00 dojo.telerik.com/afetEB or if the browser timezone is Europe/Sofia try a time between 2017-02-26 03:00 and 04:00 dojo.telerik.com/epAmob In UTC these times do exist but there is no way to display them using the JavaScript Date object

[George K]

Yep, you are absolutely right. The Date instance honors only the DST changes of the local timezone. That being said, you cannot simulate different TZ when summer DST occurs. The same limitation is applicable to the DatePicker widget which inherits the same limitation. All feasible solutions, from using custom date structures to working only with UTC milliseconds, won't work with a widget that uses Date objects internally. The most reliable solution will be to design custom widget that works only specialized data structure, which ignores local DST changes.