Currently we are using our own model but it is actually quite annoying and hard to model it.

Why not just use whatever RFC5545's VEvent defined. In summary, a VEvent can have:

1. date type start
2. date type start + day/week-wise duration (allow users to set a default duration with # of days)
3. date type start + date type end
4. Date time type start + Date time type end
5. Date time type start + duration (allow users to set a default duration)

Then, the 5 types can also to mapped to 3 different EventType:

1. one day event
2. multi-day event
3. datetime event

So this lead to 3 settable fields: DtStart, DtEnd, and Duration.

Since DtEnd and Duration are both related to the end date, we could group these two into one sealed interface.

Since we also want to support have fallbacks for some fields if one field value is missing (this can be only applicable at the same type of event), and we also want to support #9 . Hence, the new modelling would be following:

1. make ToBeMappedYouTrackIssueInfo a normal data class, and it contains a list of instances of DateTimeFieldInfo. (solve Let cliapp support mapping to different type of VEvent #9)
2. The DateTimeFieldInfo would also be a normal data class with the following fields:
   1. An enum field determining is the event is date or datetime type:
   2. An start datetime field
   3. A list of instances of a sealed interface called maybe EndDateTimeFieldInfo. (see explanation below)
   4. A list of AlarmSetting. (see Refactor the modelling of the alarm setting to be consistent with RFC5545 #8)
      The first two fields identify the DateTimeFieldInfo instance.
3. EndDateTimeFieldInfo simply have 3 subclasses of
   1. uses a dedicated end datetime field from YouTrack issue
   2. uses a dedicated duration field from YouTrack issue, with asking to be negative or positive
   3. uses a fixed duration
4. EndDateTimeFieldInfo is used for representing a multi-day event and datetime event. If the list is empty, it means no end datetime = a whole day event. The order of the list representing the attempt to create end date time or duration.
   1. e.g. The ToBeMappedYouTrackIssueInfo can contain all 3 types of EndDateTimeFieldInfo in the list. And the 3rd option "uses a fixed duration" can be the backout option if both the end datetime field and duration field is unavailable in a YouTrack issue
   2. However, if all attempts from the list is failed (e.g. a non-empty list without the "uses a fixed duration" EndDateTimeFieldInfo and all fields in that list failed to get value), then this should be traded as hard mapping failure (same level failure as missing start date), because mapping it to a whole day event may cause confusion. (or maybe we can make it a configurable setting)