2) StrSliceToRRuleSet() deliberately assumes that "floating" local
times after a DTSTART should have the same timezone as the DTSTART.
But when the RRuleSet is serialized, the RDATE and EXDATE lines are
converted to UTC making this behavior less obvious.
While there is a small risk of change in behavior for existing
applications, a timezone database change (e.g. moving daylight
saving time) is required to produce obviously different results
because users are rarely exposed to raw timestamps.
If an application depends on the old, implicit conversion to UTC,
it can be updated to explicitly convert RDATE & EXDATE values itself.
The benefit is that applications that want the RDATE & EXDATE values
in a different timezone are now able to do so.
zensh
commented
2 years ago
This fixes two issues:
1) When a rule set was round tripped (parse -> serialize -> parse -> generate) using a RRuleSet like:
DTSTART;TZID=America/Denver:20220401T000000 RRULE:FREQ=WEEKLY;INTERVAL=2;UNTIL=20220607T060000Z;BYDAY=TU RDATE;TZID=America/Denver:20220511T000000 EXDATE;TZID=America/Denver:20220510T000000
The generated timestamps would unexpectedly change timezone:
2022-04-12 00:00:00 -0600 MDT 2022-04-26 00:00:00 -0600 MDT 2022-05-11 06:00:00 +0000 UTC 2022-05-24 00:00:00 -0600 MDT
2) StrSliceToRRuleSet() deliberately assumes that "floating" local times after a DTSTART should have the same timezone as the DTSTART. But when the RRuleSet is serialized, the RDATE and EXDATE lines are converted to UTC making this behavior less obvious.
While there is a small risk of change in behavior for existing applications, a timezone database change (e.g. moving daylight saving time) is required to produce obviously different results because users are rarely exposed to raw timestamps.
If an application depends on the old, implicit conversion to UTC, it can be updated to explicitly convert RDATE & EXDATE values itself. The benefit is that applications that want the RDATE & EXDATE values in a different timezone are now able to do so.