Hello Patrick, On Dec 13, 2010, at 13:22 , Patrick Ohly wrote:
> From http://bugs.meego.com/show_bug.cgi?id=11241. Problem summary below, > patch attached. I'm a bit unsure about hard-coding UTC as time context > in that code, please suggest how this might be improved. > > [... - stored in iCalendar 2.0 format as:] > RRULE:FREQ=DAILY;INTERVAL=1;UNTIL=20111231T100000 > > [... - rendered by libsynthesis as] > RRULE:D1 20111231 > [...] > The spec says that the end date must contain a time: > > enddate::= ISO 8601_date_time value(e.g., 19940712T101530Z) I agree. There are no date-only values in vCalendar 1.0 at all. However what I don't understand is why and where the the original timestamp as represented by UNTIL=20111231T100000 becomes a date-only value as shown in the vCalendar 1.0? IMHO, this should be a date+time long before it gets into mimedirprofile. So I'd like to understand why this happens in this case. I see however a case that needs some treatment - which is when a date-only iCalendar 2.0 is the input (which then also can have a date-only UNTIL= part in the RRULE). Such a record would be rendered incorrectly in vCalendar 1.0 (as date-only). The until date/time should IMHO be handled exactly like dates with the CONVMODE_AUTOENDDATE conversion mode, which renders date-only values as floating date+time in mimo_old (vCalendar xxx), but as date-only values in MIME-DIR (iCalendar 2.0). > It does not say whether that end datetime is included in the recurrence, but > experiments show that this is the interpretation on the phone (vCalendar 1.0) > and in Evolution (iCalendar 2.0). Yes, IMHO the end date is inclusive, and can be on the exact date of the last occurrence. I have seen implementations that require the entire duration of the last occurrence to be included, so I usually set RR_END to the DTEND, not DTSTART time. These types of shaping (there's other stuff that requires similar attention, like alarms etc.) are however too dependent on the backend, so that the place to do such things is either the backend itself or the <outgoingscript>. > Given that vCalendar does not allow floating end dates, I think the encoder > for > vCalendar RRULE should be fixed to not generate such broken rules. Certainly. This is a bug. > What time it should insert as fallback might be a bit tricky, but I think the > start time of > the event should do. My suggestion (I'll propose a patch soon) would be to make RR_END behave like CONVMODE_AUTOENDDATE to handle the case of an input timestamp which is a date-only. However, this does not answer the original question why RR_END became a date-only in the example you showed. Best Regards, Lukas _______________________________________________ os-libsynthesis mailing list os-libsynthesis@synthesis.ch http://lists.synthesis.ch/mailman/listinfo/os-libsynthesis
