Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Recurring event bug #629

Open
brmckenna opened this issue Oct 31, 2024 · 3 comments
Open

Recurring event bug #629

brmckenna opened this issue Oct 31, 2024 · 3 comments
Labels

Comments

@brmckenna
Copy link

Note: we are currently on https://github.com/laget-se/ical.net which we just realized was marked archived on 10/14/24. Entering this in case this is an issue in this current library.

The following unit test demonstrates the bug of switching the start/end date on a recurring event where the initial date of 4/15/24 is somehow preserved on the object and GetOccurrences no longer returns the 4/16/2024 occurrence as a result and each occurrence has the incorrect end date of 4/15 from the initial value and a duration of -1.

[Fact]
public async Task ShouldCreateARecurringYearlyEvent()
{
    var springAdminEvent = new CalendarEvent
    {
        Start = new CalDateTime(DateTime.Parse("2024-04-15")),
        End = new CalDateTime(DateTime.Parse("2024-04-15")),
        RecurrenceRules = new List<RecurrencePattern> { new RecurrencePattern(FrequencyType.Yearly, 1) },
    };

    var calendar = new Calendar();
    calendar.Events.Add(springAdminEvent);
    var searchStart = DateTime.Parse("2024-04-15");
    var searchEnd = DateTime.Parse("2050-5-31");
    var occurrences = calendar.GetOccurrences(searchStart, searchEnd);
    Assert.Equal(27, occurrences.Count);

    springAdminEvent.Start = new CalDateTime(DateTime.Parse("2024-04-16"));
    springAdminEvent.End = new CalDateTime(DateTime.Parse("2024-04-16"));
    springAdminEvent.RecurrenceRules = new List<RecurrencePattern> { new RecurrencePattern(FrequencyType.Yearly, 1) };

    searchStart = DateTime.Parse("2024-04-16");
    searchEnd = DateTime.Parse("2050-5-31");
    occurrences = calendar.GetOccurrences(searchStart, searchEnd);

    //occurences is 26 here, omitting 4/16/2024
    Assert.Equal(27, occurrences.Count);
}

We initially correctly pull back 27 occurrences with 2024 being picked up, and a correct Period StartTime/EndTime

image

After altering the start/end date on the event we incorrectly pull back 26 occurrences and have an incorrect Period StartTime/EndTime due to somehow the old value of 4/15/2024 being preserved internally to the library. Duration is now -1 on all of the occurrences etc.

image

image

Thank you in advance for any insights!

@brmckenna
Copy link
Author

Hello,

I just confirmed this same issue exists in the latest version of this library as well.

Thank you!

@axunonb axunonb added the bug label Oct 31, 2024
minichma added a commit to minichma/ical.net that referenced this issue Nov 17, 2024
@minichma
Copy link
Collaborator

minichma commented Nov 17, 2024

It seems that this problem is fixed with #598. Didn't analyze in detail, but it seems that previous to #598 the duration of the event was considered to be -1d, so it ended on 2024-04-15, which is before the search start date of 2024-04-16, so it was excluded. With the fix it is considered to have a duration of 0d, so it works now, although the duration might still be wrong (should probably be 1d).

[Edit] The duration of 0d as calculated by #598 is correct according to RFC 5545:

The "DTEND" property for a "VEVENT" calendar component specifies the non-inclusive end of the event.

minichma added a commit to minichma/ical.net that referenced this issue Nov 17, 2024
minichma added a commit to minichma/ical.net that referenced this issue Nov 17, 2024
@brmckenna
Copy link
Author

Thank you for the info!

minichma added a commit that referenced this issue Nov 20, 2024
* CalendarEvent: Don't extrapolate a `CalendarEvent`'s `DtStart` from `DtEnd` and `Duration`. Doesn't seem to be a realistic case and prevents us from dealing with subtle differences between `DTEND` and `DURATION`.

* SymmetricSerializationTests: `VEVENT`'s `DTEND` and `DURATION` are mutually exclusive according to RFC 5545.

* CalendarEvent: Don't set `DURATION` resp. `DTEND` from each other. Only calculate the duration on the fly when needed. This way we don't overwrite the information, which of both was originally set and can adjust calculations accordingly (in the future). See #574.

* Test: Add reproducer from #629, which shows, that the problem is fixed with this PR.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants