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.

Sign up for GitHub

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

Jump to bottom

CalendarEvent mixes up DURATION and DTEND on deserialization #574

Open
minichma opened this issue May 10, 2023 · 1 comment · Fixed by #598
Open

CalendarEvent mixes up DURATION and DTEND on deserialization #574

minichma opened this issue May 10, 2023 · 1 comment · Fixed by #598
Labels
help wanted

Comments

@minichma
Copy link
Collaborator

In Ical.Net VEVENT components are deserialized into CalendarEvent objects. During the deserialization process the DURATION property is extrapolated into DTEND and vice versa. I.e. one is calculated out of the other, so after deserialziation both are present. The information, which of both was contained in the original VEVENT component is lost during deserialization.

This is a problem when it comes to recurring events, because according to RFC 5545 recurrence sets are generated differently depending on which of both was used to specify the duration.

See https://www.rfc-editor.org/rfc/rfc5545#section-3.8.5.3:

      If the duration of the recurring component is specified with the
      "DTEND" or "DUE" property, then the same exact duration will apply
      to all the members of the generated recurrence set.  Else, if the
      duration of the recurring component is specified with the
      "DURATION" property, then the same nominal duration will apply to
      all the members of the generated recurrence set and the exact
      duration of each recurrence instance will depend on its specific
      start time.

Suggestion: During deserialization retain the information, which property (DURATION, DTEND, DUE) was used to specify an VEVENT's duration.
@axunonb
Copy link
Collaborator

axunonb commented Oct 13, 2024

Appreciate a PR. Please double-check the new version merged with #595

minichma added a commit to minichma/ical.net that referenced this issue Oct 14, 2024
@minichma
CalendarEvent: Don't set DURATION resp. DTEND from each other. On…
c387516 
…ly 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 ical-org#574.
@minichma minichma mentioned this issue Oct 14, 2024
Merged
@axunonb axunonb mentioned this issue Oct 14, 2024
Open
minichma added a commit to minichma/ical.net that referenced this issue Oct 15, 2024
@minichma
CalendarEvent: Don't set DURATION resp. DTEND from each other. On…
5951a3c 
…ly 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 ical-org#574.
minichma added a commit to minichma/ical.net that referenced this issue Nov 17, 2024
@minichma
CalendarEvent: Don't set DURATION resp. DTEND from each other. On…
36a21b8 
…ly 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 ical-org#574.
minichma added a commit to minichma/ical.net that referenced this issue Nov 17, 2024
@minichma
CalendarEvent: Don't set DURATION resp. DTEND from each other. On…
6779452 
…ly 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 ical-org#574.
minichma added a commit to minichma/ical.net that referenced this issue Nov 17, 2024
@minichma
CalendarEvent: Don't set DURATION resp. DTEND from each other. On…
9a01cc8 
…ly 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 ical-org#574.
minichma added a commit that referenced this issue Nov 20, 2024
@minichma
Keep apart VEVENT.DTEND and .DURATION (#598)
2610a2d 
* 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
Assignees
No one assigned
Labels
help wanted
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Keep apart VEVENT.DTEND and .DURATION minichma/ical.net
2 participants
@minichma @axunonb