I did a little more experimentation. Here goes:
1) MS Outlook apparently imports MultiDay and ALL DAY events with a "-1" to date algorithm. This means an ALL DAY event with "DTSTART:20050504" and "DTEND:20050504" will be scheduled on "05/03/2005" or a multi-day event with "DTSTART:20050502" and "DTEND:20050504" will be scheduled as a multiday event from "05/01/2005" to "05/03/2005". This only happens to "All Day" and Multiday events. 1a) "All Day" events of a single Day duration get assigned automatically to 5:00PM. Multiday events are fine (Dunno, MS is wacko) 1b) Making the DTSTART and DTEND the same is needed for single "All Day" events (just remember to make it the day before "-1"). 2) Recurring MONTHLY events can be used if you specify a BYMONTHDAY parameter in the RRULE property (and probably will work with just a BYDAY parameter as well, but the BYMONTHDAY should be pretty easy to implement as monthly usually implies on a specific date each month [Usually]) 2a) The "-1" algorithm is overridden by the RRULE paremeters of BYDAY or BYMONTHDAY. (I took out the BYDAY paremeter of a recurring item and the "-1" date algorithm came into effect. Other than that, the entries seem to import ok. I really don't know what the solution is for the single "All Day" events getting assigned to 5:00PM, but I guess I can live with that one. Hope this helps in getting a MS Outlook supported export. :-) They really don't care too much for standards do they? Jz. Paul Lesneiwski said: >> I did a little investigation and have found a number of issues related >> to >> the iCal format of the file and the ability to import it into Outlook. >> Some at least one problem is definitely a microsoft issue, and one >> problem >> seems to be with your implementation of the iCal RFC (don't hold me to >> that, just my novice point of view after reading the RFC). > > Well, thanks for taking the time to look into it. If you found some > gold mine of MS info about what they expect out of iCal implementation > (as opposed to the RFC) please share URI or other. > >> First issue is that Microsoft's seems to be looking for a Property Name >> of >> "METHOD" (I think the RFC designates this as optional, but apparently MS >> requires it). I just set the METHOD property equal to "PUBLISH" and this >> seemed to help things along. > > Yes, this should only be required when being used as a MIME message > entity, and should correspond to the transaction type being attempted > (REQUEST, PUBLISH, etc). I'm not so sure this is correct for them to > require. But I will add it at least until I see that it breaks other > calendar apps that I consider more important than any MS product. > >> Next issue is there appears to be 2 DTSTAMP properties definied per >> VEVENT >> entry. It looks like you defined one DTSTAMP as the date the file was >> created and the other as the date the item was required. I believe the >> DTSTAMP should be the date the item was created. I'm not sure if this >> was >> interferring with the import, just something I noticed. > > That's not my interpretation of the RFC, it's a bug. :) It is fixed. > >> And here is the one I'm not sure who's problem it is: All day events are >> being defined as TWO day events when imported into Outlook. I know you >> just made a fix where you set the DTSTART and DTEND dates as sequential >> dates for all day items. This doesn't seem to go over well with >> Outlook. >> Again, I'm not sure who's issue this one is. > > I recently argued what apparently MS is arguing here. Since seeing that > several other applications do this the other way, I am going to continue > to go with the way it is now. At issue is the fact that DTEND property > is NOT INCLUSIVE, but the RFC isn't as specific as it could be when > talking about that issue as it applies to day-long events that have no > time information in them. > > If you can change the DTEND property value to be the *same* as the > DTSTART value in your all-day event and tell me that that fixes the > problem, I will provide a way for users to export calendars with > MS-compatible day-long event format. You should also try a two-day long > event, which will hopefully show up as three days in Outlook until > "fixed". Yes, making the DTSTART and DTEND the same does fix the issue. But see above for more details. >> And the last item is apparently a microsoft issue, apparently it doesn't >> like recurring entries that recur monthly. Not sure why, your export >> file >> looked fine with regards to the RRULE definition, but everytime I >> imported >> it would choke on that entry, I copied another entry's RRULE there and >> it >> worked fine. > > Well, not sure what I can do about that. If their crappy product is > broken, then who's going to be able to get them to fix it? :) Maybe > there is a work-around if someone can fish around some more... Maybe > you can create a monthly event in outlook and export it into iCal format > and tell me what the difference in their syntax is. > > Thanks again for your assistance. > > - paul > ------------------------------------------------------- This SF.Net email is sponsored by: NEC IT Guy Games. Get your fingers limbered up and give it your best shot. 4 great events, 4 opportunities to win big! Highest score wins.NEC IT Guy Games. Play to win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=20 -- squirrelmail-users mailing list Posting Guidelines: http://squirrelmail.org/wiki/wiki.php?MailingListPostingGuidelines List Address: [email protected] List Archives: http://news.gmane.org/thread.php?group=gmane.mail.squirrelmail.user List Archives: http://sourceforge.net/mailarchive/forum.php?forum_id=2995 List Info: https://lists.sourceforge.net/lists/listinfo/squirrelmail-users
