Appointment with recurrence overwrite start/end date

[a-schild]

When having appointments with recurrences, then we have no way to find the original start/end date, since they are always overwritten by the values from the "calculated" part of the JSON answer.

For example here, the event definition has start/end dates of the "Main" entry as 4.nov. 2023
But the calculated values from the recurrence overwrite this in the returned data set.
In most cases this doe snot cause an Issue, since it's what we wish, but so we don't have a way to get hold of "base start/end" and "calculated start/end" dates.

A breaking change would be to move the "calculated" start/end dates into two separate fields, but then the returned start/end dates will not be for the current occurence of the event, but for the base definition. (Which is probably what api users want in 98% of the cases)

Or we leave it as it is, and store the "base start/end" and "calculated start/end" into additional properies, this would be more api user friendly, but might cause confusions later on.

Not sure which approach you prefer

{
      "base": {
        "id": 600783,
        "caption": "Nidau: Jungschar-Nachmittag",
        "note": "EL",
        "address": {
          "meetingAt": "Bibliotheksplatz Nidau",
          "street": "Hauptstrasse 73",
          "addition": null,
          "district": null,
          "zip": "2560",
          "city": "Nidau",
          "country": "CH",
          "latitude": "47.1244565",
          "longitude": "7.2411075"
        },
        "version": 1,
        "calendar": {
          "id": 32,
          "name": "Anlässe FW und extern",
          "nameTranslated": "Anlässe FW und extern",
          "sortKey": 14,
          "color": "#f691b2",
          "isPublic": true,
          "isPrivate": false,
          "randomUrl": "Y4qjxtxPOAFutQ4A7cLriupJlaFMYvuw",
          "iCalSourceUrl": "",
          "campusId": null,
          "eventTemplateId": null,
          "meta": {
            "modifiedDate": "2018-01-24T14:22:11Z",
            "modifiedPid": 1
          }
        },
        "information": "Treffpunkt beim Bibliotheksplatz Nidau\nKontakt:\njsnidau@cevi.ch\n",
        "image": null,
        "link": "",
        "isInternal": false,
        "startDate": "2023-11-04T13:00:00Z",
        "endDate": "2023-11-04T16:15:00Z",
        "allDay": false,
        "repeatId": 999,
        "repeatFrequency": null,
        "repeatUntil": null,
        "repeatOption": null,
        "additions": [
          {
            "id": 1107,
            "date": "2023-11-18",
            "isRepeated": false,
            "meta": {
              "modifiedDate": "2023-09-05T15:50:09Z",
              "modifiedPid": 1516
            }
          },
          {
            "id": 1108,
            "date": "2023-12-02",
            "isRepeated": false,
            "meta": {
              "modifiedDate": "2023-09-05T15:50:09Z",
              "modifiedPid": 1516
            }
          },
          {
            "id": 1109,
            "date": "2023-12-16",
            "isRepeated": false,
            "meta": {
              "modifiedDate": "2023-09-05T15:50:09Z",
              "modifiedPid": 1516
            }
          }
        ],
        "exceptions": [],
        "signup": null,
        "meta": {
          "createdDate": "2023-09-05T15:50:09Z",
          "createdPerson": {
            "id": 1516
          },
          "modifiedDate": "2023-09-28T07:28:50Z",
          "modifiedPerson": {
            "id": 1
          }
        },
        "onBehalfOfPid": null
      },
      "calculated": {
        "startDate": "2023-11-18T13:00:00Z",
        "endDate": "2023-11-18T16:15:00Z"
      }
    }

I noticed this behaviour when investigating this issue:

a-schild/churchtools-wp-calendarsync#2

[DumbergerL]

I recommend incorporating extra fields for storing both the "base start/end" and "calculated start/end" as separate properties. This approach ensures that we avoid breaking changes. Additionally, it aligns with my understanding of the most logical structure. The "startDate" property is likely to be the most frequently used by users, while the "base" and "calculated" properties are designed for those who require more advanced information.

[DumbergerL]

#177