DateTime picker is adding timezone to time

[Cory]

Hi all,

I am building a web application that collects information about emergency drills, such as evacuation drills, tornado drills, etc. As you could imagine recording what time the drill was conducted is extremely important.

Well, the Kendo DateTime pickers are adding the timezone offset to the time value when the value is sent to the server. Receiving from the server works fine. 

Everybody that is using my web application is in eastern time zone, no exceptions. The timezone is GMT-5 currently. Let's use an example: a user submits a drill for 12/04/2014 1:00 PM. The time gets sent to the server but the timezone affects the time, so it will be stored in the database as 12/04/2014 6:00 PM. The timezone adds 5 hours when sent to the server. When we are in daylight savings time we are GMT-4 and 4 hours are added to the time. When my app requests the information from the server it works fine. If the server sends back 12/04/2014 1:00 PM it will display as such on the web page.

My current fix it to subtract 5 hours from the time before it is sent to the server. I don't like that because every time we go through day light savings time I have to update my code back and forth between 4 hours and 5 hours. I guess I could find the time zone from the time string and subtract whatever it is currently, but I don't like that. How can I fix this?

Thanks

[Georgi Krustev]

Hello Cory,

In general, JavaScript Date object is the one responsible for timezone adjustment, which means that every Date instance is created in local timezone and that is why the time is adjusted.
Kendo UI Date/Time pickers using Date object internally and that is why expose the same "timezone adjustment" behavior. If you would like to avoid it then you will need to handle the conversion of the dates from client -> server and from server -> client manually, like you would do without the usage of the DatePicker widget. One possible approach is to convert the dates to JSON (use JSON.stringify), where the dates will be formatted to ISO8601 format converted to UTC timezone. Thus on the server you will threat the date as UTC and the server should be able to convert it correctly.

Regards,
Georgi Krustev
Telerik

 

 

[Jon]

This remains to be a quite terrible design flaw. In Chrome, the date inputted when parsing the user input is presumed to be +0000 (UTC) instead of the machine's offset when the Date object parses the collected time, so your datetimepicker doesn't actually add the timezone. Maybe this changed since this thread was created, but right now the kendo grid is displaying in localized time (where data source is UTC or declares offset) as we expect but filtering with datetimepicker is not localized so the filter doesn't actually work, and we are having to manually hijack the datasource binding. Offset must be done on the client because only the client knows the client's timezone.

[Jon]

Apparently this is a known problem in Chrome, which requires framework tools like Kendo to implement browser-sniffing workarounds. http://stackoverflow.com/questions/15109894/new-date-works-differently-in-chrome-and-firefox

(Our stale Kendo version: v2015.3.930)

[Jon]

After further investigation I am finding that the issue is *not* with parsing the date--the datetimepicker object's .value() is localized to match the inputted text with offset--but rather with Kendo's OData v4 grid server-side filter URL generation implementation, which is not including the offset.

[Georgi Krustev]

Hello Jon,

I would suggest you override the schema.parse method:

• http://docs.telerik.com/kendo-ui/api/javascript/data/datasource#configuration-schema.parse

Thus you will take control over parsing mechanism and compensate the different in the browser behavior.

Regards,
Georgi Krustev
Telerik

 

 

[Jon]

Thank you, but no, the issue I raised in hijacking this thread (sorry about that) is not about incoming dates, this is about outgoing dates. I stepped through the code. The datetimepicker captures the date as a localized date, i.e. 1:30pm MST (-0700), and when it preps to go up to the server using the kendo.data.transports["odata-v4"] transport the URL serializer changes it to 1:30pm +0000. 

Initially the following worked, but now it doesn't, maybe because of nitpicky number of digits issues after 10pm or something.

$scope.logsGridOptions = function() {
  var options = {
    dataSource: {
      type: "odata-v4",
      transport: {
        read: { // ...
        },


        // work around bug in kendo.data.transports["odata-v4"] which fails to propagate the offset
        // by replacing date filters with ISO string
        parameterMap: function (options, type) {
          var ret = kendo.data.transports["odata-v4"].parameterMap(options, type);
          if (options.filter && options.filter.filters) {
            for (var fi = 0; fi < options.filter.filters.length; fi++) {
              var f = options.filter.filters[fi];
              function pad(n, width, z) {
                z = z || '0';
                n = n + '';
                return n.length >= width ? n : new Array(width - n.length + 1).join(z) + n;
              }
              if (f.value && f.value instanceof Date) {
                var d = f.value;
                var findRegex = new RegExp(d.getFullYear() + '-' + pad((d.getMonth()+1), 2) + '-' + pad(d.getDate(), 2) + 'T' + pad(d.getHours(), 2) + ':' + pad(d.getMinutes(), 2) + ':' + pad(d.getSeconds(), 2) + '\\+00:00');
                var newValue = d.toISOString();
                ret.$filter = ret.$filter.replace(findRegex, newValue);
              }
            }
          }
          return ret;
        }

[Georgi Krustev]

Hello Jon,

Thank you for the clarification. Indeed, it seems that current OData v4 filter serialization sends the data back to the server with incorrect timezone offset. I logged the case here with more details about the current implementation and a possible solution:

• https://github.com/telerik/kendo-ui-core/issues/1864

Until the fix is released, I would suggest you override the current ODataFilter serialization method with the given suggestion.

Regards,
Georgi Krustev
Telerik