This is a migrated thread and some comments may be shown as answers.

When a recurring appointment crosses a DST change

17 Answers 322 Views

Scheduler

This is a migrated thread and some comments may be shown as answers.

Edward Talbot asked on 21 Feb 2012, 03:14 PM

I develop a product which uses RadScheduler, and initially, our product was used in one Time Zone (GMT) and we didn't need to care about any other Time Zones. We did not apply any Time Zone offset or configuration to the RadScheduler, and generally, everything just worked.

All appointments were stored in the database in "wall clock" time (from the user's point of view), and so even across DST changes, recurring appointments worked, e.g. if you create a recurring appointment that occurred between 9am-5pm every day from 20-Mar-2012 to 28-Mar-2012, and the clocks went forward by 1 hour on 25-Mar-2012, this would all display correctly.

However, the next version of our product does need to be Time Zone aware. To this end, we have been converting all dates/times in our database to UTC, and then applying the correct Time Zone Offset to RadScheduler. For non-recurring appointments, this works. However, for recurring appointments, what happens is that the RadScheduler displays the recurring appointment correctly for 9am-5pm for 20-Mar-2012 to 24-Mar-2012 - but then moves it to 10am-6pm for 25-Mar-2012 to 28-Mar-2012.

What the user is expecting, is for the recurring appointment to appear at the same "wall clock" time - i.e. 9am-5pm on 25-Mar-2012 to 28-Mar-2012, and NOT 10am-6pm.

Now, I understand why the RadScheduler is doing this, because, presumably, the Recurrence Rule has a single fixed start/end date in UTC, and during DST, "wall clock" appointments are 1 hour ahead of UTC.

So, how do I adjust for this? Is there a way of telling the Recurrence Rule or the RadScheduler when the Start/End date of DST is, so that the RadScheduler can display the recurring appointment correctly - 9am-5pm "wall clock" time for 20-Mar-2012 to 28-Mar-2012?

17 Answers, 1 is accepted

answered on 21 Feb 2012, 06:20 PM

OK, I am sort of going to try an answer my own question here - but I would still like some input from Telerik.

The only solution I can think of is to actually not specify a TimeZoneOffset to the RadScheduler at all.

At the moment, the RadScheduler is supplied dates/times in UTC with the correct TimeZoneOffset. But instead of this, a solution could be to not specify a TimeZoneOffset - and then convert all dates/times from the database to "wall clock" time BEFORE they get bound to the RadScheduler.

Therefore, the meaning of the RecurrenceRule will be "wall clock" time.

In Microsoft Outlook, if you create a recurring appointment across a DST change, then it creates all the appointments with the same start/end times. This is what I'm trying to achieve.

answered on 27 Feb 2012, 05:31 PM

Hello Edwar,

We are aware of this behavior and we consider it to be a bug. We are now working on resolving this problem on the top of the newly released enhanced time zones support. We will fix this problem for the Service Pack, which is scheduled for the beginning of April. The fix will appear in the latest internal build as soon as it is ready. If you want, we can notify you when that happens.

Kind regards,
Genady Sergeev
the Telerik team

If you want to get updates on new releases, tips and tricks and sneak peeks at our product labs directly from the developers working on the RadControls for ASP.NET AJAX, subscribe to their blog feed now.

answered on 02 Oct 2012, 11:41 AM

Hello Jeff,

I quickly did some tests and can confirm that the problem is resolved in the latest Q2 release. I've tried both with the FLE Standard Time and Central Standard Time time zones, both of which support daylight saving.

However, if you still reproduce the problem even with the latest version please open a support ticket and attach there a sample project, where we can troubleshoot the issue.

Regards,
Genady Sergeev
the Telerik team

answered on 06 Oct 2015, 09:30 PM

I am in the "Mountain Standard Time" zone and we are currently in daylight savings time (-6:00 instead of -7:00)

I've confirmed that the TimeZoneInfo properties are showing this correctly.

I'm setting the TimeZoneID to the local timezone "Mountain Standard".

I've tried setting and not setting the TimeZoneOffset

Nothing works!

The RadScheduler is correctly displaying start and end times for appointments without recurrence.

However, recurring appointments with that were created in "standard" time (-7:00) are not displaying recurrences correctly during daylight savings (-6:00).

For example, an appointment that was created in standard time with a 17:00PM start time would display in standard time as 10:00 AM (correct). Recurrences for that event during DST should also display at 10:00 AM if the scheduler is working correctly. Instead, they are showing at 11:00 AM!

I've wasted an incredible amount of time chasing this problem!

answered on 12 Oct 2015, 01:37 PM

I was able to track down the problem.

I was setting the scheduler control to the time zone of the local machine, which was returning "Mountain Standard Time".

The problem is that we are in Colorado, which uses daylight savings time (don't get me started on the lunatic ignorance that started that or keeps it in place).

To get the correct recurrence and offset rules we needed to actually be using "US Mountain Standard Time" - which means I need to override the machine settings.

So we are now getting all of the instances of RadScheduler updated to the correct setting, but it means correcting every event in the system because they were all created with the incorrect rule set (Mountain Standard Time)!

Thanks for following up!

answered on 02 Mar 2016, 09:05 PM

Okay forget my last post - I'm back to the post of 06 Oct 2015.

The problem is that we are in "Mountain Standard Time" NOT "US Mountain Standard Time" so this needs to work for the appropriate TZ. "US Mountain Standard Time" does not support DST and does not contain any adjustment rules for processing DST.

Here's the behavior I'm seeing (which I cannot reproduce on your demo site):

I set TimeZoneID property of the Scheduler to "Mountain Standard Time" and create an appointment on Tuesday March 1, 2016 to start on Friday March 1 2016 from 7:00 a.m. to 8:00 a.m. and recurring every Monday for through December 31, 2016.

The appointments gets stored in the database as UTC (14:00 - 15:00), which is correctly -7:00.

The occurrences show on the scheduler at 7:00 a.m. - 8:00 a.m. until March 18, 2016 - where they being showing up in the scheduler 8-9 a.m. (-6:00) and continue to November 11, 2016, when they start appearing again from 7-8 a.m.

If I then switch the TimeZoneID to "US Mountain Standard Time" all occurrences show on the scheduler 7-8 a.m.

I really confused and frustrated with this whole recurrence issue and need to resolve what's going on.

Any ideas?

answered on 03 Mar 2016, 02:55 PM

The application is using 2016.1.113.40.

This was originally built using the Advanced Forms demo - with some customizations for workflow and additional data fields for the appointments. However, no modifications were made to how dates and time zones were handled, until we originally discovered the problem. At first, I tried only manually setting the TimeZoneId property - which is how I discovered that setting it to "US Mountain Standard Time" appeared to fix the problem. However, as I said earlier, that doesn't make sense because US MST doesn't support DST. I've also tried manually setting dates to UTC and back to MST programmatically - whichever is appropriate - anywhere a date is handled in the application. In all cases, the behavior is exactly the same - US MST appears to work (and shouldn't) but MST does not (and should).

answered on 15 Apr 2016, 07:58 PM

I am experiencing the same issue and in my instance i can see in the data that the recurrence rule is translated incorrectly. I have an appointment setup for 9AM EST but the recurrence rule string that was automatically generated shows:

DTSTART:20160412T140000Z
DTEND:20160412T150000Z
RRULE:FREQ=WEEKLY;UNTIL=20160601T000000Z;INTERVAL=1;BYDAY=MO,TU,WE,TH,FR

This is an hour off from my original appointment time based on current DST so my work-around has been to, when saving recurring appointments, compare the start time in the recurrence rule to the start time of the actual originating appointment and adjust the rule accordingly if the time element doesnt match. Does the trick...