RDATEs are represented in ical.net as PeriodList and therefore, when it comes to deserialization, the values of RDATEs are deserialized to instances of Period. According to the RFC RDATEs can hold any of the following value types "DATE-TIME" / "DATE" / "PERIOD".
Problems:
The information about the actual value type is lost in the Period instance. (It's still somehow accessible when looking at the PeriodList's parameters, but this doesn't seem to the intended way of using the type.)
The information about the source of the duration is lost. I.e. looking at the Period it's unclear, whether the duration has been specified in the form date-time "/" date-time or date-time "/" dur-value. The difference is relevant, because the different rules apply on how to deal with DST changes.
A related problem is described in #564, i.e. the duration value is lost if the time component equals midnight.
RDATEs are represented in ical.net asPeriodListand therefore, when it comes to deserialization, the values ofRDATEs are deserialized to instances ofPeriod. According to the RFC RDATEs can hold any of the following value types"DATE-TIME" / "DATE" / "PERIOD".Problems:
Periodinstance. (It's still somehow accessible when looking at the PeriodList's parameters, but this doesn't seem to the intended way of using the type.)date-time "/" date-timeordate-time "/" dur-value. The difference is relevant, because the different rules apply on how to deal with DST changes.A related problem is described in #564, i.e. the duration value is lost if the time component equals midnight.