While testing Job::new_async_tz on different timezones with specific set hours next_tick_for_job() was giving wrong results. On further inspection, the next_tick for every job with given timezones was being calculated wrong because the offset logic wasn't working properly while using west_opt() when calculating the fixed offset, mainly because of how signs are treated on FixedOffset.
Changing west_opt() for east_opt() should suffice as a quick fix. Also, as an alternative solution, when initially calculating time_offset_seconds in JobLocked::new_async_tz, instead of local_minus_utc(), utc_minus_local() can be used in conjunction with the original west_opt().
As an example to replicate this problem, following the README, a job can be created like this
let mut job = Job::new_async_tz("1/7 * 17 * * *", Santiago, |uuid, mut l| {
Box::pin(async move {
println!("I run async every 7 seconds");
// Query the next execution time for this job
let next_tick = l.next_tick_for_job(uuid).await;
match next_tick {
Ok(Some(ts)) => println!("Next time for 7s job is {:?}", ts),
_ => println!("Could not get next tick for 7s job"),
}
})
})?;
Pay attention to the value returned by next_tick_for_job().
While testing
Job::new_async_tz
on different timezones with specific set hoursnext_tick_for_job()
was giving wrong results. On further inspection, the next_tick for every job with given timezones was being calculated wrong because the offset logic wasn't working properly while usingwest_opt()
when calculating the fixed offset, mainly because of how signs are treated onFixedOffset
. Changingwest_opt()
foreast_opt()
should suffice as a quick fix. Also, as an alternative solution, when initially calculatingtime_offset_seconds
inJobLocked::new_async_tz
, instead oflocal_minus_utc()
,utc_minus_local()
can be used in conjunction with the originalwest_opt()
.As an example to replicate this problem, following the README, a job can be created like this
Pay attention to the value returned by
next_tick_for_job()
.