411264 - Repeating event shows up on start date even if that doesn't match RRULE line

Status: NEW

(Calendar :: General, defect)

Description

[Victor Engmark]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.11) Gecko/20071204 Ubuntu/7.10 (gutsy) Firefox/2.0.0.11
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.8pre) Gecko/20071002 Sunbird/0.7

Small test case attached: The event shows up at 07/02/2007, a Monday, which doesn't match the RRULE line ("FREQ=WEEKLY...BYDAY=TH").

Also tested for yearly events, and found the same problem.

Reproducible: Always

Steps to Reproduce:
Create a repeating event with a start date which doesn't match the repeat pattern.
Actual Results:  
The correct recurrences, plus an event on the start date, show up in the calendar.

Expected Results:  
Only the events matching the RRULE line should show up.

The work-around, of course, is to specify a start date which matches the repeat pattern.

Comment 1

[Victor Engmark]

Attachment: Test case

Comment 2

[Michiel van Leeuwen (email: mvl+moz@)]

the monday that's shown, 07/02/2007 is the dtstart of the event. I'd argue that dtstart should always be part of the set of resulting occurrences.
btw, the testcase is not valid according to rfc2445bis, which states that dtstart can't be outside the rrule.

Comment 3

[Victor Engmark]

Hunted down the actual RFC quotes:

RFC 2445 bis pp 119, 120: 'The "DTSTART" property defines the first instance in the recurrence set. The "DTSTART" property value SHOULD match the pattern of the recurrence rule, if specified. The recurrence set generated with a "DTSTART" property value that doesn't match the pattern of the rule is undefined.'

I guess this could be fixed by replacing the user entered DTSTART by the start time of the first occurrence found after DTSTART.

Comment 4

[Daniel Boelzle [:dbo]]

I think we need to separate two cases:
1) External data (not created by mozilla calendar) comes into play: simply adding the (non-fitting) DTSTART like we do is IMHO ok. It's undefined anyway.
2) Creating BYDAY rules with mozilla calendar: We should disallow creating BYDAY rules that don't fit DTSTART in the event dialog.

Comment 5

[Bernard Desruisseaux]

Recurring components where DTSTART is not synchronized with the pattern of RRULE (e.g., DTSTART is set to a Wednesday while the RRULE is weekly on Saturday) doesn't interoperate well today. According to what's been reported on the Calsify mailing list implementations are interpreting such components in one of the following ways:

a) DTSTART is an instance and is considered as part of the COUNT
   => Oracle Collaboration Suite 10g, Apple iCal, Mulberry, Zimbra, ...

b) DTSTART is an instance and is not considered as part of the COUNT
   => Mozilla Lightning/Sunbird 0.8, KOrganizer, Evolution, Google, ...

c) DTSTART is not an instance
   => Microsoft Outlook 2003, IBM Domino/Notes, Bedework, ...

http://lists.osafoundation.org/pipermail/ietf-calsify/2006-October/001293.html 

The revision of iCalendar (rfc2445bis) specifies the following new
restriction:

> The "DTSTART" property value SHOULD match the pattern of the recurrence rule,
> if specified. The recurrence set generated with a "DTSTART" property value
> that doesn't match the pattern of the rule is undefined.

As such, Mozilla calendar should not allow users to create recurring components where DTSTART is not synchronized with the pattern of RRULE.

Mozilla calendar should think carefully about how it should handle such recurring components created by other calendar clients. That is, decide with which calendar client it wants to interoperate.

Comment 6

[Philipp Kewisch [:Fallen][☁️📆]]

(In reply to Bernard Desruisseaux from comment #5)
> > The "DTSTART" property value SHOULD match the pattern of the recurrence rule,
> > if specified. The recurrence set generated with a "DTSTART" property value
> > that doesn't match the pattern of the rule is undefined.
This still stands in rfc5545

> 
> As such, Mozilla calendar should not allow users to create recurring
> components where DTSTART is not synchronized with the pattern of RRULE.
Sounds reasonable, yes.

> Mozilla calendar should think carefully about how it should handle such
> recurring components created by other calendar clients. That is, decide with
> which calendar client it wants to interoperate.
Personally I think "DTSTART is an instance and is considered as part of the COUNT" makes most sense, and given this likely requires an upstream fix in libical, actually fixing this could also align Evolution and KOrganizer.

Comment 7

[Emmanuel Surleau]

@Philipp, that's indeed what the RFC is saying. So, the bug fix is in two parts.

When the user creates a weekly-by-day event in Lightning on a day D different from a repetition day, the DTSTART from the event should be adjusted so that the first occurrence happens on the first repetition day after D. A warning with the words "The start date does not match the chosen recurrence pattern and was changed" (Philipp's suggestions, alternatives welcome) should be displayed in the notification bar. When the user updates an existing event so that it becomes a weekly-by-day event with an unsynchronized DTSTART, the DTSTART should also be adjusted and the warning displayed. However, external events (and events created from an older version of Lightning) with an unsynchronized DTSTART should be displayed the way they are now, unless their recurrence rule includes COUNT.

When an external event with an unsynchronized DTSTART and an RRULE which includes COUNT is displayed, then DTSTART *should* be considered part of COUNT (unlike the current behaviour).

Comment 8

[Philipp Kewisch [:Fallen][☁️📆]]

Sounds good to me. Bernard, do you have any thoughts on this?