Inconsistent appointment-creation on the RadScheduler demo pages (web-service vs postback in DST-switch scenarios)

[Sam]

Hi guys,

I am noticing some timezone and DST-related behavior that is confusing me on your demo pages. In particular, there seems to be an inconsistency in the way appointments are rendered when using web-services in comparison to the normal postback-style approach. I will walk you through it so that you can reproduce it and tell me if I am missing something:

Reproduction steps:
1. Change your local system timezone to (UTC + 10:00) Canberra, Melbourne, Sydney (this is my local timezone and the dates you are going to select below are related to DST switches that we have in this timezone, however this problem should theoretically be reproducible for any timezone that observes DST changes)
2. Start your browser fresh (so that your system timezone changes are persisted to it). I used the latest version of Firefox. To check that the system timezone has been persisted to the browser you can open up FireBug and execute "new Date(2000,1,1,9,0,0)" and make sure that the AUS time is shown in the result.
3. Navigate to your demo page: http://demos.telerik.com/aspnet-ajax/scheduler/examples/templates/defaultcs.aspx
4. Choose the day view on the scheduler and navigate to the date: 6 October 2013. Also choose show 24 hrs.
5. Create a new appointment starting at 01:00 (i.e. 1am) lasting for 1 hour or so and click on the create button.
6. Confirm that the new appointment is rendered correctly at 01:00.
7. Navigate to your other page that demonstrates web-service binding: http://demos.telerik.com/aspnet-ajax/scheduler/examples/webservice/defaultcs.aspx
8. Again, choose the day view and navigate to the date: 6 October 2013. Also choose show 24 hrs.
9. Again, create a new appointment starting at 01:00 (i.e. 1am) lasting for 1 hour or so.

Expected results: The appointment renders at 01:00 in the same way as step 6.
Actual results: The appointment renders at 00:00 (i.e. midnight). It appears to have been 'shifted back in time'.

The fact that there is inconsistent behavior in this scenario between web-service binding and postback binding leads me to believe that there may be an issue in the client-side script that renders the appointments that are received from the web-service responses.

I did some light debugging into your javascript and although I might be out of my depth and not understand all the aspects to the problem, I will hesitantly try to identify where I think the problem is. Consider your method...

_toClientDate:function(g){var f=new Date(g.getTime());
var h=f.getTimezoneOffset()*e;
f.setTime(f.getTime()+h);
f.setTime(f.getTime()+this._schedulerTzOffset);
return f;
}

...which is a function in the prototype of Telerik.Web.UI.Scheduler.Rendering.WebServiceRenderingManager. This method seems to be the one responsible for converting the server-received appointment times into times for displaying on the client. Now I don't have time to look into this in depth, however it seems that in the line...

var h=f.getTimezoneOffset()*e;

...you're getting the client-timezone offset of the time BEFORE it has been adjusted by the scheduler timezone offset. In the case that a DST switch is involved, this leads to the one-hour discrepancy that we see in the scenario described above. Without researching it further my gut feeling is that such an offset should be applied AFTER it has been adjusted by the scheduler timezone offset (but I could definitely be wrong on this).

If you were to follow the same approach for the date 7 April 2013 you would see the switch happen the other way (i.e. the appointment is rendered forward one hour). Again this is due to the DST switch (this time going in the opposite direction).

I guess some logical questions might be: how does your logic handle it on the server-side in the postback case, and can this same logic be applied at the client-side so that the web-service binding scenario matches the postback scenario?

We are using web-service binding on our project and this issue is of concern to us. If we are missing something fundamental here then please let us know, otherwise we would appreciate if you could comment on the timeline for resolving this problem, and if there are any workarounds that we can implement. For example, I imagine we might be able to tap into the client 'OnRequestSuccess' method and adjust the dates appropriately in these situations if required...perhaps you could suggest an appropriate code snippet for this.

Cheers,
Sam

[Sam]

After some further investigation and debugging, we have come up with a workaround for our problem. Although we don't like to mess with code that's external to our application, we decided to hook into the OnClientAppointmentsPopulating event and replace your definition of the _toClientDate with one we came up with ourselves:

function OnClientAppointmentsPopulating() {
    Telerik.Web.UI.Scheduler.Rendering.WebServiceRenderingManager.prototype._toClientDate = function (g) {
        var utcDateTime = new Date(g.getTime()); // get the UTC time passed from the server
        var schedulerDateTime = new Date(utcDateTime.getTime() + this._schedulerTzOffset); // convert to the timezone of the scheduler
        var clientOffsetSchedulerTime = schedulerDateTime.getTimezoneOffset() * 60000; // find the offset "normally" required to get it to client time (in cases involving no DST switch)
        var candidateClientTime = new Date(schedulerDateTime.getTime() + clientOffsetSchedulerTime); // get the candidate client time by adding the offset to the scheduler time
        var clientOffsetCandidateTime = candidateClientTime.getTimezoneOffset() * 60000; // get the offset at the candidate client time
        var correctedClientTime = new Date(candidateClientTime.getTime() + (clientOffsetCandidateTime - clientOffsetSchedulerTime)); // adjust for DST if necessary
        return correctedClientTime;
    };
}

Now although we haven't tested this extensively (we just tested it against a couple of scheduler time-zone offsets around DST-switch times), it seems to have solved our problem.

Again, we're struggling to imagine that such a bug (if it is indeed one) would have made it into your client-side scripts, so perhaps we really are missing something fundamental. As such, we look forward to your opinion on the problem and our proposed workaround. Until then we will continue with our workaround because it seems to be doing the job nicely for us.

Cheers,
Sam

[Boyan Dimitrov]

Hello,

Your observations are absolutely correct and the RadScheduler populated from a web service does not work as expected when the daylight-saving time is changed. We are planning to fix that issue for our next official release Q2 2013 scheduled for middle of June this year.
We have made some researched and concluded that we will implement similar behavior as provided in the Microsoft Outlook 2013 - we will hide the that specific hour from the time picker control when the daylight-saving time is changed and shift its appointment start time if user tries to create an appointment in that specific hour.
Additionally I have tried the provided workaround for our  toClientDate function, but it does not change the default behavior. Could you please confirm that this workaround works fine for your time zone and behave
fine with a regular days when the daylight-saving time is not changing (for example 10th of October)?

Regards,
Boyan Dimitrov
the Telerik team

[Kees]

Hi,

I'm expeciencing the same issue, has this been solvend yet? I'm using Q2 2013.

Thanks,
Kees

[Boyan Dimitrov]

Hello Kees,

I am afraid that your observations are correct and the described behavior is not implemented in Q2 2013. As soon as there is an update regarding this issue we will include information in our release history.

Regards,
Boyan Dimitrov
Telerik