Problem with occurrences method

[Miguel Baldi]

Hi folks,

I'm experiencing a problem when I try to call occurrences method on an
event, the method attempt to loop thru the events following the rules
specified, but never ends! Seems to be an infinite loop problem.
I've tried to identify the fields that may cause the problem, but I
had no luck. I suspect from DTSTART or DTEND, maybe the rule itself.

I wrote a sample code to show this behavior:

require 'rubygems'

require 'net/http'

require 'uri'

require 'time'

require 'ri_cal'

require "tzinfo"

rawdata = <<END_STR
BEGIN:VCALENDAR
PRODID:-//Google Inc//Google Calendar 70.9054//EN
VERSION:2.0
CALSCALE:GREGORIAN
METHOD:PUBLISH
X-WR-CALNAME:RICal teste
X-WR-TIMEZONE:America/Sao_Paulo
X-WR-CALDESC:
BEGIN:VTIMEZONE
TZID:America/Sao_Paulo
X-LIC-LOCATION:America/Sao_Paulo
BEGIN:DAYLIGHT
TZOFFSETFROM:-0300
TZOFFSETTO:-0200
TZNAME:BRST
DTSTART:19701018T000000
RRULE:FREQ=YEARLY;BYMONTH=10;BYDAY=3SU
END:DAYLIGHT
BEGIN:STANDARD
TZOFFSETFROM:-0300
TZOFFSETTO:-0300
TZNAME:BRT
DTSTART:19700215T000000
RRULE:FREQ=YEARLY;BYMONTH=2;BYDAY=3SU
END:STANDARD
END:VTIMEZONE
BEGIN:VEVENT
DTSTART;VALUE=DATE:19400713
DTEND;VALUE=DATE:19400714
RRULE:FREQ=YEARLY;BYMONTH=7;BYMONTHDAY=13
DTSTAMP:20091109T161426Z
UID:CD0000008B9511D182D800C04FB1625DF48568F41595384496C2570C025DC032
CREATED:20090924T160743Z
DESCRIPTION: Description test 12
LAST-MODIFIED:20090924T160945Z
LOCATION: Location test 12
SEQUENCE:0
STATUS:CONFIRMED
SUMMARY: Event test 12
TRANSP:TRANSPARENT
END:VEVENT
END:VCALENDAR
END_STR

cals = RiCal.parse_string(rawdata)

puts "Parsing executed!"

cal = cals.first

cal.events.each do |event|

unless event.recurs?

puts "Dont recurs!"

else

puts "Recurs!"

occrs = event.occurrences({:count => 10})

puts "Occurrences size #{occrs.size}"

occrs.each do |ev|

puts "Event #{ev.summary}"

end

end

end

puts "Events collected!"

Maybe I am doing something wrong, if so, please let me know!

Any ideas?!
Thanks guys

Miguel Baldi

[Miguel Baldi]

Any ideia?

[Adam Williams]

I ran your code and it fails for me! I can confirm that it ends up in a loop around property_value/recurrence_rule/occurrence_incrementer/frequency_incrementer.rb:57. That seems good, since there is a FREQ=YEARLY bit in your RRULE. Some how I saw dates of January 1 - it would seem that the thing should not get off the month 7, day 13 bit. Also, the year 1954 was a date I saw in the debugger. Why would it go back before 1970?

I did delete this bit from the RRULE:

;BYMONTH=7;BYMONTHDAY=13

So, with just the FREQ=YEARLY part, it works. I don't know why they put that in there (since it's redundant), but I don't know why it won't work with it.

We should have paid Rick enough to keep him from getting a job! :)

Adam

[Rick DeNatale]

Yes it seems to be a bug.

I'll get to it as soon as I can.

--
Rick DeNatale

Blog: http://talklikeaduck.denhaven2.com/
Twitter: http://twitter.com/RickDeNatale
WWR: http://www.workingwithrails.com/person/9021-rick-denatale
LinkedIn: http://www.linkedin.com/in/rickdenatale

[Miguel Baldi]

Actually, this piece of calendar was extracted/imported from google
calendar. I don't know why the rule is redundant too, maybe a little
bug from google guys ;-)
Thanks for attention, I will keep debugging here, looking for
something suspicious.

[Rick DeNatale]

I fixed the particular case this weekend but I still have a bit more
work to do before releasing it as a gem.

I've pushed it to github and to rubyforge, so folks can have a look, etc.

Although the rules are redundant given the particular dtstart, there's
another case where the dtstart doesn't fall within the recurrence
rules, and that's the case which is producing incorrect results, and
which I want to fix before pushing out a new gem.

Look in the new spec in
spec/ri_cal/inf_loop_spec.rb

and the commit message for more details.
http://github.com/rubyredrick/ri_cal/commit/226fcf9bb6200d9478578d535cd5af615d511d59

[Miguel Baldi]

Thanks Rick. i'm so glad by your attention.
I will try the new code.

On Nov 16, 10:32 pm, Rick DeNatale <rick.denat...@gmail.com> wrote:
> I fixed the particular case this weekend but I still have a bit more
> work to do before releasing it as a gem.
>
> I've pushed it to github and to rubyforge, so folks can have a look, etc.
>
> Although the rules are redundant given the particular dtstart, there's
> another case where the dtstart doesn't fall within the recurrence
> rules, and that's the case which is producing incorrect results, and
> which I want to fix  before pushing out a new gem.
>
> Look in the new spec in
>   spec/ri_cal/inf_loop_spec.rb
>

> and the commit message for more details.http://github.com/rubyredrick/ri_cal/commit/226fcf9bb6200d9478578d535...