Open niccokunzmann opened 1 month ago
A problem that I see with this approach is that icalendar
works more on the specification level than the semantic level: An event can have an RRULE and RDATE and this will not work with these.
However, this is a good start. Whoever likes, can set DTSTART of the event to another time and then check the alarms - they will only be calculated on the first, core instance of events and TODOs.
I wonder, how we would like to handle these things in general - I like the interface of the dict to access the specified properties and subcomponents. Any special 'read' functionality can be put in such properties.
It seems to be nicer to have another interface. The problem is this:
What is required to compute an alarm fully:
The result is:
Events and TODOs can contain alarms. These alarms can be acknowledged.
For https://github.com/niccokunzmann/python-recurring-ical-events/issues/186, in order to calculate which alarms hit within a time span, I would like to get a list from the VEVENTs and VTODOs of the corresponding alarms and whether they are snoozed.
My proposal
According to RFC 9074, we can snooze or acknowledge an alarm.
The problem as pointed out by RFC 9074 is that the VALARM component in conjunction with RFC5545 only had no defined way to acknowledge an alarm. Thus, the attributes of event.alarms and todo.alarms will take care of compatibility issues. E.g. Thunderbird saves the dates of the acknowledged alarm time in the VEVENT. Thus this cannot just be a property of VALARM but must reside in the VEVENT.
See also
657
I will open a PR.