I seem to have an issue with biweekly recurrence, with these two patterns (the start date is in 2000 as i only have the demo at the moment, we are waiting untill we have evaluated all your componets so we can get them all together)
1) DTSTART:20000201T115050
RRULE:FREQ=WEEKLY;INTERVAL=2;BYDAY=SU
2) DTSTART:20000201T114950
RRULE:FREQ=WEEKLY;INTERVAL=2;BYDAY=MO
the occurrences generated dont appear to be what is expected.
1) 2000-02-01
2) 2000-02-01
1) 2000-02-06
2) 2000-02-14
1) 2000-02-20
2) 2000-02-28
You may notice that Sunday is next sunday and Monday is next monday + a week.
i would expect either
1) 2000-02-01
2) 2000-02-01
1) 2000-02-06
2) 2000-02-07
1) 2000-02-20
2) 2000-02-21
or
1) 2000-02-01
2) 2000-02-01
1) 2000-02-13
2) 2000-02-14
1) 2000-02-27
2) 2000-02-28
On my system monday is the start of the week and sunday is the end if that makes any difference.
If the startdate is on a Wednesday and BYDAY is set to WE, TH, FR, SA or SU its the next occurrence of that day and if BYDAY is set to MO or TU its an extra week away.
But if startdate was Thursday and BYDAY is set to TH, FR, SA or SU its the next occurrence of that day and if BYDAY is set to MO, TU or WE its an extra week away.
I hope i explained that well enough, my brain has been fried with date stuff for a few days (building a outlook style interface for iCalendar is harder than it looks, but im soo close)
I only noticed this issue because i am trying to make the start date the actual first occurrence to prevent the start date from appearing if it isn’t a part of the recurrence pattern so i initally thought that it was a bug in my ‘interesting’ code that decides the actual start date. So i saved iCal string and loaded it into the demo and i get the same problem.
This may be related to the Aspose.Recurrence bug described in that forum under Incorrect dates calculated by Weekly recurrence which was fixed on the 7th of jan, but then again it might not be.
- The system adds 2000-02-01 start date to the list of occurrences.
2. The system takes all days of the week that are after the start date, but in the start week’s date. In your examples, Sunday 2000-02-06 will be in the start week’s date, but Monday 2000-02-07 will be in the next week so it is not taken.
3. The system adds 2 weeks interval and takes the specified day(s) of week from that week. This yelds Sunday 2000-02-20 for the first example and Monday 2000-02-14.
I hope that explains the behaviour. I think WKST (start of the week) might affect calculations in your case.
We also think that including start date in the list of occurrences always is not a very good idea, but this is what iCalendar RFC2445 requires and we complied. You might try using EXDATE to exclude the start date specifically, but of course you risk excluding it when it is one of the recurring occurrences. I’m open to your suggestions on how you want to see this working for you.
Aspose.iCalendar is a completely new and different code base from Aspose.Recurrence so no issues from Aspose.Recurrence could have made their way to Aspose.iCalendar.
That kind of makes sense actually, i think i will just document the behaviour instead of trying to do anything about it, thanks for getting back so quickly.
While looking up the WKST in the API reference i noticed there is no way to actually add that without tinkering with the iCal string manually, same for the Time zone identifier, is that that going to change soon, and does the timezone id actually do anything yet as we will want the to convert it to UTC for storage and then to local time when someone opens it (which isnt too hard to implement manually but if i dont need to id prefer not to)?
Im not quite sure how it builds the result set (i seem to recall reading it the other day but i cant find it now) but if it was possible to get a boolean property that we can set to change whether its added explicitly or not (breaking the RFC2445) it doesnt need to be serialized its just in certain situations it would be nice to ignore some of the stupid parts of the standard, it really depends on what one it trying to accomplish.
WKST (RecurrenceRule.WeekStart in the API model) was added relatively recently and it can be set or get so you can do it via API.
Timezones are currently ignored, so I suggest you treat everything as local time. There is some confusion in the standard we have not sorted out yet, for example, the standard says that date time in UNTIL has to be specified in UTC format, but all examples in the standard treat date time in UNTIL as local time.
You don’t need to use timezone id in your patterns if you don’t want too. See the standard (and I think this is mentioned in the API documentation too), date time can be specified in several formats.
I agree, it is reasonably hard to grasp how the dates and times of occurrences are calculated, but that’s the way it is in the standard.
ahh i searched the api help for WKST and all i could find was instances in the iCal string didnt try all the variations.
The only problem i face is the occurences will be generated on the server which could be in a difference timezone, so UTC conversion on save and ToLocal on load will be our only choice, basicly what im doing for any non fixed dates in the rest of the database, so its no biggy.
Thanks for all your help sometimes working with standards can be a pain.