schedule.occurrences hangs in some scenarios

[mhenrixon]

The following code hangs for some reason and I can't figure out why.

schedule = IceCube::Schedule.from_yaml <<-EOS
:start_date: 2012-09-03 00:00:00.000000000 +00:00
:end_time: 2022-09-15 00:00:00.000000000 +00:00
:rrules:
- :validations: {}
  :rule_type: IceCube::DailyRule
  :interval: 1
:exrules: []
:rtimes: []
:extimes: []
EOS
schedule.occurrences(Date.new(2013, 07, 13).to_time)

Any suggestions?

[seejohnrun]

Doesn't hang for me - what time zone are you in?

[mhenrixon]

Time.zone
=> (GMT+00:00) UTC

Actually I am in Stockholm time but the rails app is configured for UTC.

[mhenrixon]

I just added the following commit mhenrixon/ice_cube@19b01ae and locally ice_cube fails.

[mhenrixon]

Added the repository to our build server that is California time and the spec fails but doesn't hang.

[mhenrixon]

Added some logging and it seems that at the specific date 2013-03-30 02:00:01 +0100 the looping stops

"next_time (2013-03-30 02:00:00 +0100) fetched ok"
"res (2013-03-30 02:00:00 +0100) is greater than or equal to opening_time (2012-09-03 02:00:00 +0200)"
"didn't break because no limit"
"time (2013-03-30 02:00:01 +0100) is less than closing_time (2013-07-13 00:00:00 +0200)"

If I add a break for break if time >= Time.new(2013, 03, 30) then the array is returned ok otherwise ice_cube just hangs forever.

EDIT This actually happens on our CI server as well when we use different time zones in our specs to catch any errors due to not specifying the users time_zone in our background workers.

[mhenrixon]

Further investigation shows that it's next_time that hangs.

[mhenrixon]

rule.next_time loops indefinitely

[mhenrixon]

It seems that the ScheduleLock validation locks the date at 2013-03-31 and never let's go of that date so it loops indefinitely.

[mhenrixon]

Ok so this is what is really going on it's all in the TimeWrapper and the problem is with adjust. I added comments telling what goes wrong but I still have no idea how to solve the problem.

def adjust(&block)
    # @dst_adjust is true because of differece in time zones
    if @dst_adjust
        off = @time.utc_offset
        # offset is 3600
        yield
        diff = off - @time.utc_offset
        # offset is either -3600 or zero
        @time += diff if diff != 0
        # time is for either reason set back to it's original value
        # no change is done what so ever and the same date is returned
        # time and time again.
    else
        yield
    end
end

[mhenrixon]

@seejohnrun any suggestions?

[mhenrixon]

Ok now I really know what the bottom line problem is. The date 2013-03-31 is the day we change to daylight savings time in Sweden Europe next year!

[mhenrixon]

@seejohnrun do you have any suggestions or is this project dead?

[seejohnrun]

The project is not dead - I'm dealing with some personal matters the past few weeks. I'm sorry for the delay

[seejohnrun]

I'll be taking a look at this tonight and hopefully will have something for you

[seejohnrun]

Okay - so I'm about to put in a fix for this, but I want to write up a bit about what's going on and some expected caveats, which come as a result of iCalendar's specification

If you specify a recurring rule with IceCube as you have, you will end up with no occurrence in your time zone on the date when jumping back over DST (the 31st), since that time does not exist at that hour. Its easy to jump through time at regular intervals, harder to try to repeat events at a consistent time each day when the time you're repeating on isn't always there.

That being said, the hanging is fixed. It will go out with v0.9.0 likely tomorrow afternoon after I remove the deprecations and integrate a few more fixes

---

Really, issues like this are the heart of what make this library so compelling - there are countless issues with DST, TZ, weekdays, and month lengths that had to be figured out to make any of this work. My apologies for the hanging and the delay

A fun read: http://fanf.livejournal.com/104586.html

[mhenrixon]

Trust me I know about those issues by now! Great fix, I did about that same thing in a couple of other places but never thought to do it there. I was a little confused with the break if @validations.all? do |name, vals| part of the code.

Thank you for the clarification, maybe next time I'll be able to submit a pull request.

[seejohnrun]

Any time - thanks for the report