Bug Report T632271
Visible to All Users

The Scheduler does not save recurrence exceptions in the start date time zone with the hotfix of the T619455 ticket

created 7 years ago

[DevExpress Support Team: CLONED FROM T619455: Daylight Savings not considered in exception rule for recurring appointment]
Hi Nikita ,

I did the investigation and realized that the fix seems to be incorrect.

Previously, before the fix, the recurrence exception dates were added in the timezone of recurring appointment ( startDate timeZone).
Now it is been changed and exception dates are added in browser/users timeZone( which is incorrect).

This leads to existing issue, wherein if the recurring appointment crosses the daylight saving dates, recurrence exception won't work.

For example,

if an appointment is starting from 22nd March and daylight have changed on 1st April.
Recurrence exception won't work.

I would expect the solution to add the recurrence exception in startDatetimeZone.

Comments (1)
DevExpress Support Team 7 years ago

    Hi Peter,

    I see that the recurrence exception is not saved in either the startDate time zone or in UTC. But, I can't reproduce the issue that recurrence exceptions don't work because of daylight saving time with the attached project. I've also attached a screencast to illustrate how it works for me. Would you please modify my project to reproduce this issue? In any case, we will research the behavior with an incorrect time zone for recurrence exceptions. Watch for our updates in this thread.

    Answers approved by DevExpress Support

    created 7 years ago (modified 6 years ago)

    We have fixed the issue described in this ticket and will include the fix in our next maintenance update. To apply this solution before the official update, request a hotfix by clicking the corresponding link for product versions you require.

    Note: Hotfixes may be unavailable for beta versions and updates that are about to be released.

    Additional information:

    After the fix, the behavior will be as follows:

    1. If startDate has the UTC format (e.g., 2018-03-22T08:30:00.000Z"), the exception time ('8:30') will  converted to the browser time zone (e.g., T083000 -> T103000)
    2. If startDate is a JavaScript Date object (e.g.,  new Date(2018, 5, 10, 8, 30) ),  the time part will remain the same(e.g., T083000)
      Show previous comments (1)
      Artem (DevExpress Support) 7 years ago

        Hi,

        The hotfix will be available once all tests are passed. You'll get an email notification about this. Please bear with us.
        After the fix, the behavior will be as follows:

        1. If startDate has the UTC format (e.g., 2018-03-22T08:30:00.000Z"), the exception time ('8:30') will  converted to the browser time zone (e.g., T083000 -> T103000)
        2. If startDate is a JavaScript Date object (e.g.,  new Date(2018, 5, 10, 8, 30) ),  the time part will remain the same(e.g., T083000)

        Let us know if you have additional questions.

          I need the opposite behavior where the exception time is stored using the timeZone of the scheduler and not the local browsers time zone.  How can that now be accomplished?  As of 18.1.7, the recurrenceException is using the right day but local time zone.

          Artem (DevExpress Support) 6 years ago

            Hi Greg,

            To process your inquiry more efficiently, I've created a separate ticket on your behalf (T687347: Scheduler - recurrence exception should take into account the timeZone option value). Please refer to it for further correspondence.

            Disclaimer: The information provided on DevExpress.com and affiliated web properties (including the DevExpress Support Center) is provided "as is" without warranty of any kind. Developer Express Inc disclaims all warranties, either express or implied, including the warranties of merchantability and fitness for a particular purpose. Please refer to the DevExpress.com Website Terms of Use for more information in this regard.

            Confidential Information: Developer Express Inc does not wish to receive, will not act to procure, nor will it solicit, confidential or proprietary materials and information from you through the DevExpress Support Center or its web properties. Any and all materials or information divulged during chats, email communications, online discussions, Support Center tickets, or made available to Developer Express Inc in any manner will be deemed NOT to be confidential by Developer Express Inc. Please refer to the DevExpress.com Website Terms of Use for more information in this regard.