Proper handling of time zones and DST

[Eric]

We're currently using an older version of Telerik (from 2009).  We are located in Arizona. DST has always been a huge hassle for us, requiring manual editing of appointments for customers in areas that do DST (e.g. all but Arizona).  Example: It's Friday, and the DST switch-over happens on Sunday. If they schedule an appointment for Monday in Mountain time, the UTC time saved to the database will be an hour off.  This requires us to edit the offsets on every time zone on the scheduler (except Arizona), but it's nearly impossible to time this edit in such a way that eliminates a huge pile of mis-scheduled appointments twice a year. People seriously dread "DST week" in our office because it means overtime spent correcting scheduling mistakes and calling customers.

I noticed that in the most recent update, it was mentioned that the time zone handling has become more advanced.  In the documentation it was unclear if this new functionality would help us to correctly handle DST.  Is there anywhere I can read more about the "CustomTimeZones" referred to in the changelog?  We are trying to decide if it is worth re-purchasing Telerik for this (it most certainly would be if let us handle DST correctly).

Also, any additional insight as to how we can properly handle DST would be much appreciated.  We currently only deal with Pacific, Mountain, Arizona, Central, and Eastern.

Thanks!

[Plamen]

Hi Eric,

 
Yes, we are well aware of all of the DST problems and are actively working on resolving them. We will do our best to have all time zones related issues resolved for the upcoming service pack plus adding export to ICal that handles time zones.
  
Hope this information will be helpful. 

All the best,
Plamen Zdravkov
the Telerik team

[Eric]

Thanks for the response. I look forward to future updates that improve DST handling. 

Can you also please explain what additional DST functionality is in the latest release that I linked to in my original post? I could not find documentation that explained this.

[Plamen]

Hi Eric,

 
In the Q1 2012 release we have added the new TimeZoneID property of RadScheduler and the new DataTimeZoneIdField so that each appointment can be associated with its own specific time zone. These fields are not changing much in the current day light saving functionality but they are preparing RadScheduler for the further improvement.

Before that change only the TimeZoneOffset property was used for handling similar functionality and it was not enough if we wanted to covering all the cases in this scenario.

Hope this information will be helpful.

Kind regards,
Plamen Zdravkov
the Telerik team