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