Does the Kendo grid assume all my dates are UTC?

[Randy]

I'm running into a situation in my MVC app where the Kendo grid seems to be assuming that my date columns are UTC dates and are converting them to local time. Most of my dates are off by one day. 

First of all, is this what the grid is doing? Past posts about issues like this seems to confirm it. If so, can I tell the Kendo grid that my dates are not UTC? We're building an app around an existing database where the dates are not stored as UTC and the dates cannot be converted. If I can't tell the Kendo grid to stop doing this, what alternatives do I have? I know I can represent dates as strings in the grid, but then I lost the ability to sort correctly if the user chooses to sort a date column. Converting all date columns in our database to UTC is not an option.

 

[Stefan]

Hello Randy,

The described result is expected.

I can suggest checking the following forum thread which contains a custom approach and examples how the desired result can be achieved:

http://www.telerik.com/forums/kendo-grid-automatically-converting-timezone

Currently, this is the recommended approach, as the built-in one is treating the dates as UTC.

Regards,
Stefan
Telerik by Progress

[Randy]

Has Telerik considered changing this default behavior? To assume that every date field in every database that may appear in a Kendo grid will be stored in UTC time is ridiculous. How hard can it be to provide a grid option named something like 'UtcDates' and if it's false, don't convert to local time?

[Stefan]

Hello Randy,

Thank you for the feedback.

Still, based on the provided link in the linked forum this is because of the specifics of the JavaScript Date object:

http://stackoverflow.com/questions/8883362/javascript-date-preserve-timezone-offset

I can also, suggest submitting a feature request, and based on its popularity our developers` team will inspect it and provide this option if possible:

http://kendoui-feedback.telerik.com/forums/127393-kendo-ui-feedback/category/170280-grid?query=UTC

Regards,
Stefan
Telerik by Progress

[John]

My team experiences the same problem, but there's more to it than is being described here.

We DO store dates in a SQL database as UTC, but we have some fields that are really datatype "Date", and the time part is irrelevant. However, because there is no time part, it defaults to all zeroes, which is the absolute beginning of the day. Then the localization subtracts N hours and that changes the day by one, which is NOT what we need on those fields.

In our MVC models they are either DateTime or Nullable<DateTime> type because obviously that's what has to be used in .NET. We annotate those fields with "[DataType(DataType.Date)]", but of course this has no effect on how the grid renders the values.

It seems to me that the core problem here is the default behavior of the javascript Date object. Therefore Telerik probably should consider using another means of managing dates (perhaps even consider using Moment?) in order to provide more flexible options to developers using the grid. It certainly should be possible for a developer using a grid to indicate that specific date fields should NOT be localized. Right now having to run custom script code for every single date field in our system to get it to render properly seems a bit stupid.

[Angel Petrov]

Hi,

We do have logic that can modify the dates according to certain requirements. One can always subscribe to the schema.parse method of the grid datasource and using the convert method alter the dates. If a built-in solution is desirable I would recommend logging a descriptive feature request which we can evaluate and applicable integrate into our code-base.

Regards,
Angel Petrov
Progress Telerik

[John]

Interesting suggestion. So if we subscribe to schema.parse and we do something with a date, will it then go through the same process it does normally? In other words, would that code need to compensate in advance for the fact that the Date() object will be localizing the value?

[Angel Petrov]

Hello,

Indeed this is the general idea, to compensate the offsets using JavaScript.

Regards,
Angel Petrov
Progress Telerik