You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
RDATE
s are represented in ical.net asPeriodList
and therefore, when it comes to deserialization, the values ofRDATE
s are deserialized to instances ofPeriod
. According to the RFC RDATEs can hold any of the following value types"DATE-TIME" / "DATE" / "PERIOD"
.Problems:
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.)date-time "/" date-time
ordate-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.
The text was updated successfully, but these errors were encountered: