For Multisync, this has been fixed in CVS. Someone else noticed they had a problem rweekdays not being set (they didn't track down why, but obviously you have...) so they provided a patch to set rweekdays if the other recurrence information is provided.
I applied this patch to CVS a few days ago, so it will be present in the next Multisync release. Thanks, Tom On Mon, 2003-09-22 at 13:26, Akim Demaille wrote: > Hi people, > > I have a bug that took me a while to track down. This bug is that > opie's datebook hangs for ever on a datebook.xml created by multisync > from a evolution file. I believe that the problem is that some > entries from Evolution are not complete, multisync lets this pass > (Garbage In, Garbage Out), and datebook fails to realize the entry is > incomplete. > > The entry in evolution's ~/evolution/local/Calendar/calendar.ics looks like: > > BEGIN:VEVENT > UID:[EMAIL PROTECTED] > DTSTAMP:20021003T145245Z > DTSTART;TZID=/softwarestudio.org/Olson_20011030_5/Europe/Paris: > 20021007T153000 > DTEND;TZID=/softwarestudio.org/Olson_20011030_5/Europe/Paris: > 20021007T183000 > TRANSP:OPAQUE > SEQUENCE:9 > SUMMARY:Compil > LOCATION:EPITA > CLASS:PUBLIC > RRULE;X-EVOLUTION-ENDDATE=20021209T143000Z:FREQ=WEEKLY;COUNT=10; > INTERVAL=1 > EXDATE;VALUE=DATE:20021111 > END:VEVENT > > > Compared to other repeting events (that do work), there is no BYDAY field. > Multisync transforms this entry into > > <?xml version="1.0" encoding="UTF-8"?> > <!DOCTYPE DATEBOOK><DATEBOOK> > <events> > <event uid="173030560" description="Compil" note="Compil" location="EPITA" > start="1034008200" end="1034017200" created="1033649565" rtype="Weekly" rfreq="1" > rhasenddate="0" /> > </events> > </DATEBOOK> > > note that there is no "rweekdays" in it. When I add one, taking > inspiration from another entry that does work: > > <event uid="1869308419" description="Piscine Prenatale" note="Piscine Prenatale" > start="1062693000" end="1062707400" created="1063777943" rtype="Weekly" rfreq="1" > rhasenddate="0" rweekdays="8" /> > > then magically datebook works properly. > > I suspect that evolution is now "fixed": I no longer have entries like > this in more recent dates, so maybe it's done. Nevertheless, I think > that evolution should upgrade older entries to have complete fields. > > Multisync should probably be more strict and at least emit a few > warnings for such incomplete fields. > > Finally, it is abnormal from opie's datebook to hang indefinitely on > the small datebook.xml I posted above, so it should be fixed too. > > Thanks to you all. As a disclaimer I wish to emphasize that I may > have incorrectly suspect some package to have performed something > invalid (e.g., evolution may be fully right to have such records). > But I'm only a user, so that's only a wild guess. > > Akim > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Multisync-users mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/multisync-users ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Multisync-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/multisync-users
