When a recurring appointment crosses a DST change

18 posts, 0 answers
  1. Edward Talbot
    Edward Talbot avatar
    6 posts
    Member since:
    Oct 2009

    Posted 21 Feb 2012 Link to this post

    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?

  2. Edward Talbot
    Edward Talbot avatar
    6 posts
    Member since:
    Oct 2009

    Posted 21 Feb 2012 Link to this post

    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.
  3. UI for ASP.NET Ajax is Ready for VS 2017
  4. Genady Sergeev
    Admin
    Genady Sergeev avatar
    1596 posts

    Posted 27 Feb 2012 Link to this post

    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.
  5. Jeff Breuninger
    Jeff Breuninger avatar
    2 posts
    Member since:
    Mar 2007

    Posted 27 Sep 2012 Link to this post

    Was this issue ever resolved?  I am working with version (2012.2.912.40) and exporting events which cross the DST change still results in them showing up an hour early in Outlook.

    Any help would be greatly appreciated.
  6. Genady Sergeev
    Admin
    Genady Sergeev avatar
    1596 posts

    Posted 02 Oct 2012 Link to this post

    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
    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.
  7. Randy
    Randy avatar
    26 posts
    Member since:
    Jul 2013

    Posted 06 Oct 2015 in reply to Genady Sergeev Link to this post

    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!

     

  8. Plamen
    Admin
    Plamen avatar
    2730 posts

    Posted 09 Oct 2015 Link to this post

    Hello,

    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
    Do you want to have your say when we set our development plans? Do you want to know when a feature you care about is added or when a bug fixed? Explore the Telerik Feedback Portal and vote to affect the priority of the items
  9. Randy
    Randy avatar
    26 posts
    Member since:
    Jul 2013

    Posted 12 Oct 2015 in reply to Plamen Link to this post

    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!

  10. Randy
    Randy avatar
    26 posts
    Member since:
    Jul 2013

    Posted 02 Mar Link to this post

    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?

  11. Plamen
    Admin
    Plamen avatar
    2730 posts

    Posted 02 Mar Link to this post

    Hi,

    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
    Do you want to have your say when we set our development plans? Do you want to know when a feature you care about is added or when a bug fixed? Explore the Telerik Feedback Portal and vote to affect the priority of the items
  12. Randy
    Randy avatar
    26 posts
    Member since:
    Jul 2013

    Posted 03 Mar in reply to Plamen Link to this post

    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).

  13. Plamen
    Admin
    Plamen avatar
    2730 posts

    Posted 07 Mar Link to this post

    Hello,

    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
    Do you want to have your say when we set our development plans? Do you want to know when a feature you care about is added or when a bug fixed? Explore the Telerik Feedback Portal and vote to affect the priority of the items
  14. Randy
    Randy avatar
    26 posts
    Member since:
    Jul 2013

    Posted 07 Mar in reply to Plamen Link to this post

    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?

     

  15. Plamen
    Admin
    Plamen avatar
    2730 posts

    Posted 08 Mar Link to this post

    Hello,

    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
    Do you want to have your say when we set our development plans? Do you want to know when a feature you care about is added or when a bug fixed? Explore the Telerik Feedback Portal and vote to affect the priority of the items
  16. Randy
    Randy avatar
    26 posts
    Member since:
    Jul 2013

    Posted 11 Apr in reply to Plamen Link to this post

    Finally got around to this. Is there a place to upload a zip or someone specific I should send it to?
  17. Plamen
    Admin
    Plamen avatar
    2730 posts

    Posted 11 Apr Link to this post

    Hello,

    You can submit a support ticket and attach the isolated page there.

    Regards,
    Plamen
    Telerik
    Do you need help with upgrading your ASP.NET AJAX, WPF or WinForms projects? Check the Telerik API Analyzer and share your thoughts.
  18. Dmitri
    Dmitri avatar
    12 posts
    Member since:
    May 2011

    Posted 15 Apr Link to this post

    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...

  19. Plamen
    Admin
    Plamen avatar
    2730 posts

    Posted 19 Apr Link to this post

    Hi,

    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
    Do you need help with upgrading your ASP.NET AJAX, WPF or WinForms projects? Check the Telerik API Analyzer and share your thoughts.
Back to Top
UI for ASP.NET Ajax is Ready for VS 2017