Kendo UI Scheduler incorrectly converting times, adding and subtracting hours backwards

Question

I am using the Kendo scheduler and the timezone offset appears to be adding hours and subtracting hours in the opposite direction from what should happen.

When I change my client timezone to a more western timezone, hours are added to the event date times and when I change my client browser to a more eastern timezone, hours are subtracted.

So a client in the Pacific timezone should see the start time as 10:00 AM, but instead it is displaying as 4:00PM. Clients set to the Atlantic timezone see the start time as 12:00PM.

Scheduler code:

$("#scheduler").kendoScheduler({
    date: new Date(),
    height: 900,
    editable: false,
    views: [
        {
            type: "month",
            selected: true,
            eventHeight: 50,
            eventTemplate: $("#event-template-month").html(),
        },{
            type: "agenda",
            eventHeight: 50,
            eventTemplate: $("#event-template-sched").html(),
        }
    ],
    timezone: "America/New_York",
    dataSource: webinarSchedule,
});

The event information is held in an array in a local js file and looks like this:

var webinarSchedule = [//Date are in utc -5:00
{
    title: "Part 1 <br/>The Golden Rule",
    shortName: "1) The Golden Rule ",
    presenter: "Bill Preston",
    description: "A great event",
    synopsis: "Learn stuff",
    seriesNote: "The first of a 4-part series.",
    registration: "https://attendee.gotowebinar.com/register/3782113333237861889",
    start: new Date("2015/1/24 1:00 PM"),
    end: new Date("2015/1/24 1:20 PM"),

},

Answer 1

Yeah, that doesn't seem to work right.

I find the only way to keep your sanity when dealing with JS dates (or dates in computing in general) is to use UTC dates, serialized in ISO format (in general, storing UTC dates on the server is also a better idea). So, I'd suggest creating your events using the appropriate ISO string for the source timezone:

{
    title: "Part 1 <br/>The Golden Rule",
    shortName: "1) The Golden Rule ",
    presenter: "Bill Preston",
    description: "A great event",
    synopsis: "Learn stuff",
    seriesNote: "The first of a 4-part series.",
    registration: "https://attendee.gotowebinar.com/register/3782113333237861889",
    start: new Date(Date.parse("2015-02-11T13:00:00-05:00")), 
    end: new Date(Date.parse("2015-02-11T13:20:00-05:00")),
}

then don't set the schedulers timezone option at all (so it uses local). If you need to pass to the server, you may also want to process the dates first using toISOString.

Answer 2

The Scheduler expects to receive and send only UTC dates - that why you should load it's data in correct format with UTC timezone (otherwise when the date is created from the string, local user timezone will be used, which is JavaScript specific behaviour):

start: new Date("2015-01-24T13:00:00.000Z"),
end: new Date("2015-01-24T13:20:00.000Z"),

Additionally you can set the Scheduler timezone to "Etc/UTC" - this way the above dates will be shown as-is without conversion on the client side:

$("#scheduler").kendoScheduler({
   date: new Date("2015/1/24"),
   timezone: "Etc/UTC",

Here is a JSFiddle based on your code snippets above showing this: http://jsfiddle.net/loanburger/0s3Lcq17/

Answer 3

A little late to the show but I am currently evaluating Telerik's MVC components and had a similar issue when working with the scheduler. The way I handled it was to make timezone required and then server side I did the following:

public SchedulerViewModel HandleTimezonesToUTC(SchedulerViewModel e)
{
    TimeZoneInfoHelper tziHelper = new TimeZoneInfoHelper();
    if (!string.IsNullOrEmpty(e.StartTimezone) && string.IsNullOrEmpty(e.EndTimezone))
    {
        TimeZoneInfo tzi = TimeZoneInfo.FindSystemTimeZoneById(tziHelper.FindMSEquilivalent(e.StartTimezone));
        e.Start = DateTime.SpecifyKind(e.Start, DateTimeKind.Unspecified);
        e.End = DateTime.SpecifyKind(e.End, DateTimeKind.Unspecified);
        e.Start = TimeZoneInfo.ConvertTimeToUtc(e.Start, tzi);
        e.End = TimeZoneInfo.ConvertTimeToUtc(e.End, tzi);
    }
    if (!string.IsNullOrEmpty(e.StartTimezone) && !string.IsNullOrEmpty(e.EndTimezone))
    {
        TimeZoneInfo tziStart = TimeZoneInfo.FindSystemTimeZoneById(tziHelper.FindMSEquilivalent(e.StartTimezone));
        TimeZoneInfo tziEnd = TimeZoneInfo.FindSystemTimeZoneById(tziHelper.FindMSEquilivalent(e.EndTimezone));
        e.Start = TimeZoneInfo.ConvertTimeToUtc(e.Start, tziStart);
        e.End = TimeZoneInfo.ConvertTimeToUtc(e.End, tziEnd);
    }
    return e;
}

public SchedulerViewModel HandleTimezonesFromUTC(SchedulerViewModel e)
{
    TimeZoneInfoHelper tziHelper = new TimeZoneInfoHelper();
    if (!string.IsNullOrEmpty(e.StartTimezone) && string.IsNullOrEmpty(e.EndTimezone))
    {
        TimeZoneInfo tzi = TimeZoneInfo.FindSystemTimeZoneById(tziHelper.FindMSEquilivalent(e.StartTimezone));
        e.Start = DateTime.SpecifyKind(e.Start, DateTimeKind.Utc);
        e.End = DateTime.SpecifyKind(e.End, DateTimeKind.Utc);
        e.Start = TimeZoneInfo.ConvertTimeFromUtc(e.Start, tzi);
        e.End = TimeZoneInfo.ConvertTimeFromUtc(e.End, tzi);
    }
    if (!string.IsNullOrEmpty(e.StartTimezone) && !string.IsNullOrEmpty(e.EndTimezone))
    {
        TimeZoneInfo tziStart = TimeZoneInfo.FindSystemTimeZoneById(tziHelper.FindMSEquilivalent(e.StartTimezone));
        TimeZoneInfo tziEnd = TimeZoneInfo.FindSystemTimeZoneById(tziHelper.FindMSEquilivalent(e.EndTimezone));
        e.Start = TimeZoneInfo.ConvertTimeFromUtc(e.Start, tziStart);
        e.End = TimeZoneInfo.ConvertTimeFromUtc(e.End, tziEnd);
    }
    return e;
}

By doing it this way you are removing any accidental local->utc conversions and as one of the other posters said let the browser adjust back to local time for you.

In theory you should not need the fromUTC but when I was testing the calendar was not converting it down to the local timezone. You might be able to get away with just assigning a "kind" but I did not test that.

Not sure what you are working in but hopefully it will help you clear up some of your wibbly wobbly timey wimey issues.

Answer 4

I solved this issue by using moment.js

Javascript:

new Date(moment.utc("INSERT DATE HERE").format())

That way I am eliminating the timezone issue. I do not alter the date on the MVC Controller whatsoever.