Hey Paul, Wow, thanks for working on this! Yeah, regarding the MONTHLY, it won't work (at least for me in Outlook 2003) unless I specify the MONTHDAY parameter in the RRULE property. So something like:
RRULE:FREQ=MONTHLY;INTERVAL=1;COUNT=12;BYMONTHDAY=29 seems to work, but the following will not work: RRULE:FREQ=MONTHLY;INTERVAL=1;COUNT=12 That is what I found. Regarding the ALL DAY event, whenever I import this: BEGIN:VEVENT UID:sm_cal_evt_20050420T060554Z_zuck_com SEQUENCE:0 PRIORITY:5 CREATED:20050420T060554Z LAST-MODIFIED:20050420T060554Z STATUS: DTSTART:20050503 SUMMARY:Mungolaya Water Change DESCRIPTION: COMMENT: DTEND:20050503 RRULE:FREQ=WEEKLY;INTERVAL=3;UNTIL=20050831T140000Z DTSTAMP:20050420T060554Z END:VEVENT it is scheduled at 5:00PM... Dunno. Jz. Paul Lesneiwski said: > > Joel Zucker wrote: >> I did a little more experimentation. > > Thank you! > >> 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. > > Preposterous. MS *does* have some smart people working for it. I can't > imagine that they'd do something *that* stupid. I wouldn't be surprised > if it's just a different RFC interpretation or file format > incompatibility. > > A-ha. The problem is the missing ;VALUE=DATE AFAIKT. Yes, this appears > to fix it for me. All together, dates for all-day events should now > look like: > > DTEND;VALUE=DATE:20040123 > >> 1a) "All Day" events of a single Day duration get assigned automatically >> to 5:00PM. Multiday events are fine (Dunno, MS is wacko) > > I don't see this. Maybe my fix above corrected it. > >> 1b) Making the DTSTART and DTEND the same is needed for single "All Day" >> events (just remember to make it the day before "-1"). > > My fix seems to have gotten this working properly. > >> 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]) > > I can't even get this to work: > > RRULE:FREQ=MONTHLY > > Might be a bad combination of other properties that it freaks out on, > but the lack of any good error message makes this hard to figure out. > Montly events created in Mozilla calendar do the same thing, so I'm > afraid this time Outlook may be buggy and you'll have to suffer the > consequences unless you can do some more digging, which you seem to have > been doing a good job with. > > I tested using LookOut 2002. > > Thanks. > > - paul > > >> 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
