exception_times not used on next_occurence

[bitboxer]

Somehow the exception_times is not correctly used in next_occurence creation.

In our software we have:

schedule.exception_times
=> [Sun, 27 May 2012 19:00:00 CEST +02:00]

And this is the result of next_occurence on that element:

schedule.next_occurrences(12)
=> [2012-05-27 19:00:00 +0200, 2012-06-21 19:00:00 +0200, 2012-06-24 19:00:00 +0200, 2012-07-19 19:00:00 +0200, 2012-07-29 19:00:00 +0200, 2012-08-16 19:00:00 +0200, 2012-08-26 19:00:00 +0200, 2012-09-20 19:00:00 +0200, 2012-09-30 19:00:00 +0200, 2012-10-18 19:00:00 +0200, 2012-10-28 19:00:00 +0100, 2012-11-15 19:00:00 +0100]

The first Item should not be there.

[romaind]

I had the same issue.
It's a .round problem on your time. It seems it can't compare times if one has milliseconds and the other one don't.

All this depends on the format of the start_time of you schedule I guess.

So now, I go with schedule.next_occurences(12, Time.zone.now.round) and it works

[bitboxer]

Yes, but this should be fixed in ice_cube. I have a workaround in place for that.

[seejohnrun]

Fix will go out with v0.9.0 - thanks!

[bitboxer]

Are you sure that this is fixed? I removed the workaround I introduced to our codebase and tried 0.9.1, but it failed. Our current work around is not to use the miliseconds part of the timestamp and check against the exclude list manually.

Basically what we did was:

schedule.next_occurrences(12).each do |occurrence|
    # TODO: Hot-Fix for ice_cube's issue #83
    occurrence = occurrence.without_ms

    if !schedule.extimes.map(&:to_i).include? occurrence.to_i
       # Okay, the occurrence is not in our extimes list
    end
 end

and without_ms is a method on the Time class that creates a copy of the Time object with ms = 0

[seejohnrun]

Ah - I see the issue you're running into - there will be a fix for this in 0.9.2 - I'll reopen now and add some more detail tonight

[bitboxer]

Any update on this?