On Di, 2010-12-14 at 11:43 +0000, Lukas Zeller wrote:
> 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).

That's exactly the situation here.

> 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).

You are not suggesting to use convmode="auto[end]date" as it is, right?
If I read the documentation right, it will turn 20101231 into either
20101231T235959 (<autoenddateinclusive>) or 20101231T000000. In both
cases it would cut off the last occurrence on day 20101231.

But I can see how converting to 20101231T235959 might work. My goal in
the patch was to recreate exactly the same RRULE as sent by the Nokia
phone, with the right time embedded in it. Not sure whether that is
really necessary, perhaps something larger would also work.

> > 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.

Okay. Let me know when it is ready and I'll redo my tests.


-- 
Best Regards, Patrick Ohly

The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.



_______________________________________________
os-libsynthesis mailing list
os-libsynthesis@synthesis.ch
http://lists.synthesis.ch/mailman/listinfo/os-libsynthesis

Reply via email to