next_occurrence skipping one occurrence
Highly likely that I am doing something wrong/using this gem incorrectly, but I am encountering an issue. We are using icecube essentially to track/manage biweekly schedules, so what I am doing may be a little unusual. My setup: schedule yaml:
---
:start_time: 2019-07-17 00:10:00.000000000 Z
:rrules:
- :validations:
:day:
- 3
:hour_of_day:
- 3
:rule_type: IceCube::WeeklyRule
:interval: 2
:week_start: 0
:rtimes: []
:extimes: []
aka Every 2 weeks on Wednesdays on the 3rd hour of the day
Using Timecop to set my current time:
time = Time.zone.local(2019, 7, 17, 0, 10) # => Wed, 17 Jul 2019 00:10:00 UTC +00:00
Timecop.db_safe_freeze(time)
Here's the weird part:
user_utc_offset = -8
last_run_at = Time.zone.local(2019, 7, 10, 3 - user_utc_offset, 0)
schedule.
tap { |r| r.start_time = last_run_at + user_utc_offset }.
next_occurrence(last_run_at) # I feel requiring last_run_at here is a bug
Basically, given some past date, I would like to know the next relevant Wednesday, assuming the two week cadence is maintained. In this case, since I update the schedule's start_time to 7/10, I would expect a schedule of [7/10, 7/24, 8/7]. And indeed, if I change the line to
tap { |r| r.start_time = last_run_at + user_utc_offset; puts r.occurrences(Time.now + 1.month).inspect } I end up with: [Wed, 10 Jul 2019 03:00:00 UTC +00:00, Wed, 24 Jul 2019 03:00:00 UTC +00:00, Wed, 07 Aug 2019 03:00:00 UTC +00:00]. Here's the issue: If I call next_occurrence without last_run_at I get back Wed, 07 Aug 2019 03:00:00 UTC +00:00 while if I pass in last_run_at, I get back Wed, 24 Jul 2019 03:00:00 UTC +00:00. In my head, given that the date is spoofed to be July 17, shouldn't the next_occurrence be July 24th?
Thanks for your time and assistance in advance!
Hi @allentsai,
I've recently joined the project and am helping with maintenance and support. Since it's been a little while since you opened this ticket, I thought it's worth asking if you still have an issue before I delve into solutions/feedback. If you no longer need any help, or have since found that there isn't a bug, we can close this issue.
Cheers, Jon