Subject: Issue 63 Re: [Ietf-calsify] Section 4.8.5.3 Recurrence Date/Times: RDATE < DTSTART

From: lear at cisco.com (Eliot Lear)
Date: Thu Feb 8 07:37:00 2007

I would like to know if there are objections to this Issue being 
accepted and the text being included, subject to clarifying text about 
VTIMEZONE.

Thanks,

Eliot

Bernard Desruisseaux wrote:
> Reinhold,
>
> In my opinion we need to allow RDATE to be less than DTSTART,
> even more so now that DTSTART should be synchronized with the
> recurrence rule.
>
> Let's say I want to have a meeting today (Monday) with three
> further instances on the next upcoming Tuesday. I could easily
> do that with an RDATE set to today (Monday) and a DTSTART set
> to tomorrow (Tuesday) and RRULE:FREQ=WEEKLY;BYDAY=TU;COUNT=3.
>
> Cheers,
> Bernard
>
> Reinhold Kainhofer wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Am Sonntag, 5. November 2006 23:33 schrieb Bernard Desruisseaux:
>>> In section 4.8.5.3 Recurrence Date/Times of RFC 2445 it says:
>>>  > The "DTSTART" property defines the first instance in the
>>>  > recurrence set.
>>>
>>> I believe this section should clarify that the "RDATE" property
>>> value can actually be earlier in time than the value of the
>>> "DTSTART" property.
>>
>> I always understood this sentence that the DTSTART is always the 
>> first date/time of the event and RDATE cannot be earlier. Otherwise, 
>> to determine whether an event happens today, one would have to look 
>> at all recurrences of all events, future or past. If the DTSTART is 
>> always the first time, then it suffices to look at all events that 
>> have already started at the given date (i.e. DTSTART<=givenDateTime).
>>
>> Cheers,
>> Reinhold
>> - -- - 
>> ------------------------------------------------------------------
>> Reinhold Kainhofer, Vienna University of Technology, Austria
>> email: [email-masked], http://reinhold.kainhofer.com/
>>  * Financial and Actuarial Mathematics, TU Wien, 
>> http://www.fam.tuwien.ac.at/
>>  * K Desktop Environment, http://www.kde.org, KOrganizer maintainer
>>  * Chorvereinigung "Jung-Wien", http://www.jung-wien.at/
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG v1.4.3 (GNU/Linux)
>>
>> iD8DBQFFTvUFTqjEwhXvPN0RAsPDAJ4n+XOsCnoXHjZIfHS//FrbChScywCfeHY6
>> RUXtgVx4DX3mzyaAq+CT9j4=
>> =5sgz
>> -----END PGP SIGNATURE-----
>> _______________________________________________
>> Ietf-calsify mailing list
>> [email-masked]
>> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify
> _______________________________________________
> Ietf-calsify mailing list
> [email-masked]
> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify
>

---

From: bernard.desruisseaux at oracle.com (Bernard Desruisseaux)
Date: Thu Feb 15 12:54:30 2007

At the Jabber session held on February 8, 2007 we had consensus to
modify the draft to clarify that "RDATE" can specify a value earlier
in time than "DTSTART" in "VEVENT", "VTODO" and "VJOURNAL" calendar
components but more discussion was deemed necessary for "VTIMEZONE".

I'm not aware of any restriction in RFC 2445 that would prevent one
to specify an "RDATE" property that specifies a value earlier in time
than the "DTSTART" property in a "VTIMEZONE" component.

To find the offset to apply to a given time one needs to determine
the observance that has the last onset date and time before the
time in question, and use the offset value from that observance.
All sub-components should be taken into account when doing so.

Speak up if you have any concerns to apply the clarification to
"VTIMEZONE" components as well.

Cheers,
Bernard

---

From: gsexton at mhsoftware.com (George Sexton)
Date: Thu Feb 15 13:06:26 2007

What sort of intoxicants are served at these meetings?

How in the universe does this make sense?

The DTSTART is not really the DTSTART?

Are there other instances or cases when DTSTART is not DTSTART?

Bernard Desruisseaux wrote:
>> accepted and the text being included, subject to clarifying text 
>> about VTIMEZONE.
>>
>> Thanks,
>>
>> Eliot
>>
>>>> first date/time of the event and RDATE cannot be earlier. 
>>>> Otherwise, to determine whether an event happens today, one would 
>>>> have to look at all recurrences of all events, future or past. If 
>>>> the DTSTART is always the first time, then it suffices to look at 
>>>> all events that have already started at the given date (i.e. 
>>>> DTSTART<=givenDateTime).
>>>>
>>>> Cheers,
>>>> Reinhold
>>>> - -- - 

-- 
George Sexton
MH Software, Inc.
Voice: +1 303 438 9585
URL:   http://www.mhsoftware.com/

---

From: bernard.desruisseaux at oracle.com (Bernard Desruisseaux)
Date: Thu Feb 15 13:45:20 2007

Hi George,

"DTSTART" specifies the start date and time of a single recurrence
instance. In a recurring component, this recurrence instance is
always the first instance generated by the "RRULE". I don't see
any reason to restrict this recurrence instance to be the first
instance of the entire recurrence set.

What exactly does it mean to be the first instance? To be the
first instance to occur based on its original start time (i.e.,
"RECURRENCE-ID") or to be the first instance to occur based on
its effective start time?  Does it really matter?

One can reschedule any recurrence instance earlier in time than
the recurrence instance defined by "DTSTART". I see no reason to
prevent one from defining an additional recurrence instance with
an original start time earlier in time than "DTSTART".

Cheers,
Bernard

---

From: gsexton at mhsoftware.com (George Sexton)
Date: Thu Feb 15 13:54:18 2007

Foolish consistency is the hob-goblin of small minds.

I guess I'm small minded.

I think that having a field labeled DTSTART, which is not actually the 
first occurrence of a set is a bad idea.

It actually doesn't break any of my code, but I still think it's a bad idea.

Take a candidate item:

DTSTART:20070205
RDATE:20070120,20070127,20070228

I could see someone else writing some code that goes along these lines:

- Display a calendar for January 2007
- Step 1 - Get the candidate set of items
- Step 2 - Eliminate all candidate items that have a DTSTART after 31 
January 2007. Then, we can avoid all of the really expensive and compute 
intensive items that we know don't occur.
- Step 3 - Your clever, poorly written entry just got bounced.

This a bad idea and should be ditched.

There's no justifiable benefit. Some developer can get a little sloppier 
writing his file. In the meantime every potential consumer has to look 
out for it.

---

From: cyrus at daboo.name (Cyrus Daboo)
Date: Fri Feb 16 07:13:41 2007

Hi George,

> first occurrence of a set is a bad idea.

Just as DTEND does not represent the end of the last occurrence in the set?

> - Step 3 - Your clever, poorly written entry just got bounced.

It is a trivial matter to include tests on any RDATEs in that procedure. 
Maybe it is worth putting a note in 2445bis's DTSTART section explaining 
that the DTSTART may not represent the first instance start in the instance 
set, and that RDATE should be checked if present.

But ultimately it is an implementation issue - anyone using a database or 
index to handle instance sets will likely not care as they may have 
expanded the set out already and will do time-range queries using that 
data. Anyone manipulating iCalendar data directly in their database will 
need to pay attention to this.

> writing his file. In the meantime every potential consumer has to look

You already have to look out for it - the original 2445 never expressly 
ruled out RDATE < DTSTART. Also, it allows EXDATE == DTSTART, which means 
that DTSTART would no longer represent the first instance start time. That 
would result in a false positive following your steps 1-3 above.

Either way 2445bis is being more explicit about this so that everyone is 
aware of what can possibly happen.

-- 
Cyrus Daboo

---

From: gsexton at mhsoftware.com (George Sexton)
Date: Fri Feb 16 08:43:58 2007

Silly me.

I keep thinking the standard should be written in such a way as to make 
a correct implementation simpler and more likely to happen. Instead, 
this standard is all about pedantically describing a whole universe of 
silly, possible cases. This is a perfect example. There's no GOOD reason 
to allow this. It adds no functionality, but instead adds useless 
complication. Instead of explicitly codifying what' wasn't explicitly 
said before, this should be explicitly forbidden because it adds no 
functionality, only complexity.

In a lot of ways, the whole conversation is totally pointless. 
Evolution, Outlook, KOrganizer, Sunbird, PHPiCalendar, and Apple iCal 
don't support RDATE events. In short, you're describing a part of the 
spec that no one (aside from my company) actually implements anyhow...

As far as your comments about my test case go, my test case was meant to 
demonstrate a optimization that a developer would likely to be come up 
with. Having an EXDATE the same as DTSTART would not have actually 
broken my test case. The item with an EXDATE would have remained in the 
set of candidate items, where it would have had the expensive tests 
done, but it would not have been eliminated from the candidate set. This 
EXDATE/DTSTART is another stupid case. Who thinks this stuff up? Has 
anyone here besides me actually written a calendar that was good enough 
other people would pay money for it?

In regards to your comments about DTEND not representing the last 
element in the set. You're right. Personally, I think the whole idea of 
determining the duration for recurring event from the DTEND was a stupid 
idea. Using DURATION would have been much simpler, and using DTEND 
brings in all sorts of wormy problems of dealing with DST transitions. 
It should never have been done.

I've always believed that the real goal of RFC-2445 was to make the 
standard so complex that it would never be possible to have applications 
that could share data. It's reassuring to see that this isn't changing.

Cyrus Daboo wrote:
> It is a trivial matter to include tests on any RDATEs in that 
> procedure. Maybe it is worth putting a note in 2445bis's DTSTART 
> section explaining that the DTSTART may not represent the first 
> instance start in the instance set, and that RDATE should be checked 
> if present.
>
> But ultimately it is an implementation issue - anyone using a database 
> or index to handle instance sets will likely not care as they may have 
> data. Anyone manipulating iCalendar data directly in their database 
> will need to pay attention to this.
>
> You already have to look out for it - the original 2445 never 
> expressly ruled out RDATE < DTSTART. Also, it allows EXDATE == 
> DTSTART, which means that DTSTART would no longer represent the first 
> instance start time. That would result in a false positive following 
> your steps 1-3 above.
>
> Either way 2445bis is being more explicit about this so that everyone 
> is aware of what can possibly happen.
>

---

From: reinhold at kainhofer.com (Reinhold Kainhofer)
Date: Fri Feb 16 09:23:04 2007

> spec that no one (aside from my company) actually implements anyhow...

We (KOrganizer) don't have a gui option for it (yet?), but korganizer (or 
rather libkcal) perfectly understands RDATEs (and EXRULEs, by the way).
A quick test indicates that RDATE<DTSTART seems to work, but I cannot 
guarantee that there are no complications (e.g. implicit assumptions that 
rdate>=dtstart used somewhere). At least while coding, I was always thinking 
that dtstart<=rdate. So if it works now, it's simply by coincidence...

Cheers,
Reinhold

- -- 
- ------------------------------------------------------------------
Reinhold Kainhofer, Vienna University of Technology, Austria
email: [email-masked], http://reinhold.kainhofer.com/
 * Financial and Actuarial Mathematics, TU Wien, http://www.fam.tuwien.ac.at/
 * K Desktop Environment, http://www.kde.org, KOrganizer maintainer
 * Chorvereinigung "Jung-Wien", http://www.jung-wien.at/

---

From: gsexton at mhsoftware.com (George Sexton)
Date: Fri Feb 16 09:36:47 2007

> A quick test indicates that RDATE<DTSTART seems to work, but I cannot 
RDATE doesn't work at all in KOrganizer 3.5.5. Look at the entry for the 
Tanner Gun Show in

webcal://www.mhsoftware.com/caldemo/iCal/calendar_id/8.ics

Is there a version new than 3.5.5 where RDATE does work?

Additionally, 3.5.5 displays one time events that are in GMT with the 
time in GMT, and not local time.

> Version: GnuPG v1.4.6 (GNU/Linux)
>
> iD8DBQFF1eg2TqjEwhXvPN0RAlK1AKCGUy52PEXheAgTZ5ietz9Btes7KQCgsZh7
> VVCrHFWJKnpZDyskuA834yg=
> =YOSl

---

From: reinhold at kainhofer.com (Reinhold Kainhofer)
Date: Fri Feb 16 10:47:47 2007

Am Freitag, 16. Februar 2007 schrieb George Sexton:
> RDATE doesn't work at all in KOrganizer 3.5.5. 

Touch?! Apparently in the method Incidence::doesRecur() we only checked if 
there are any rrules (but forgot to check for rdates, too)... So as long as 
an event has also rrules, the rdates worked.

Actually, our unit tests didn't use doesRecur(), so we didn't find that 
problem so far.

> Look at the entry for the 
> Tanner Gun Show in
>

3.5.7 will have the fixes in (I just committed them). Screenshot at
http://www.fam.tuwien.ac.at/~reinhold/KOrganizer/KOrganizer_RDates.jpg
(TZ is Europe/Vienna, which is UTC+1 in winter)

> time in GMT, and not local time.

Another stupid mistake (in korganizer 3.x we didn't support timezones 
properly, but only used the first one for all times if one was present in the 
file; Fixed that now to apply only to non-utc times.).

Cheers,
Reinhold

- --