There's a calculation inconsistency between Sidekiq and have_enqueued_job when using perform_in with a days or months ActiveSupport::Duration, and the current time is before a daylight savings time change, and the job is scheduled after the time change.
Awesomejob.perform_in 7.days, 'Awesome' converts the current time and the 7.days to floats and then adds them together, resulting in a scheduled time that is 168 hours from now.
expect(AwesomeJob).to have_enqueued_sidekiq_job('Awesome').in(7.days) adds 7.days to the current time, then converts it to a number. But a Time + an ActiveSupport::Duration with units of months or days will adjust to be at the same time of day on the other side of a daylight savings time boundary. So, it will expect the job to be scheduled 7 days from now at the same time of day. In my case, in America/Denver on 2022-03-09, that would be 167 hours instead of 168.
There's a calculation inconsistency between Sidekiq and
have_enqueued_jobwhen usingperform_inwith a days or monthsActiveSupport::Duration, and the current time is before a daylight savings time change, and the job is scheduled after the time change.Awesomejob.perform_in 7.days, 'Awesome'converts the current time and the7.daysto floats and then adds them together, resulting in a scheduled time that is 168 hours from now.expect(AwesomeJob).to have_enqueued_sidekiq_job('Awesome').in(7.days)adds 7.days to the current time, then converts it to a number. But a Time + an ActiveSupport::Duration with units of months or days will adjust to be at the same time of day on the other side of a daylight savings time boundary. So, it will expect the job to be scheduled 7 days from now at the same time of day. In my case, inAmerica/Denveron 2022-03-09, that would be 167 hours instead of 168.