Rank 1
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
Rank 1
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.
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
Rank 1
Any help would be greatly appreciated.
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
Rank 1
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!
I have tested the issue but unfortunately could not observe it at my side. Would you please elaborate it a little bit and share the exact mark up and steps to replicate it at our side. Please test if it is can be also replicated on our online demo here.
Regards,
Plamen
Telerik
Rank 1
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!
Rank 1
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?
I have tested the scenario locally but unfortunately could not replicate it at our side. Would you please elaborate what is the difference in your scenario and our online demo and which is the version of our controls that you are using?
Regards,
Plamen
Telerik
Rank 1
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).
Thank you for sharing this information. Yet we could not replicate the issue at our side. Would you please share the exact mark up and steps to replicate the issue so we could inspect it locally and log it for fixing?
Regards,
Plamen
Telerik
Rank 1
The application is AD-authenticated and has a lot of extra code for event management.
Do you want the whole project or just the code base that saves appointments and displays them in the scheduler?
You can simply share the exact mark up and code behind connected to RadScheduler that you are using and the steps to replicate the issue.
Regards,
Plamen
Telerik
Rank 1
You can submit a support ticket and attach the isolated page there.
Regards,
Plamen
Telerik
Rank 1
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...
Would you please elaborate if the unusual issue can be replicated with this online demo so we could inspect it locally and be more helpful?
Regards,
Plamen
Telerik