Closed nailus closed 4 years ago
It looks like it's a bug indeed, thanks for reporting, we'll look into it !
Note that 24.working.hours
from now works as expected, it might be voluntary.
I think adding advance_to_working_time
in add_days
should do the trick. WDYT @jarthod ?
Replied in #39 :+1:
Hi @nailus, we changed the behaviour in version 1.2.0
We kept the relation between dates and times the same as before, meaning that when we add days, we only care about days, and not about the time, for example :
WorkingHours::Config.holidays = [Date.today]
WorkingHours::Config.working_hours = { mon: { '17:00' => '18:00' }, tue: { '17:00' => '18:00' }, wed: { '17:00' => '18:00' }, thu: { '17:00' => '18:00' }, fri: { '17:00' => '18:00' } }
1.working.day.from_now # Fri, 17 Apr 2020 08:29:24 UTC +00:00
Even if the current time is not worked, adding 1 working day from a time will only add the correct amount of days, but will not change the time component.
Thanks again for reporting this issue !
if date.current is holiday or weekend (Date.current.working_day? returned false) then when calculating
1.working.days.from_now
the calculation is still made from the current day. For example:puts DateTime.current
WorkingHours::Config.working_hours = { mon: { '09:00' => '18:00' }, tue: { '09:00' => '18:00' }, wed: { '09:00' => '18:00' }, thu: { '09:00' => '18:00' }, fri: { '09:00' => '18:00' } }
WorkingHours::Config.holidays = ["14 Apr 2020"]
puts 1.working.day.from_now
is this a bug? I believe that the calculation should start at 9:00 on the first business day and
puts 1.working.day.from_now
should returnedWen, 16 Apr 2020 09:00:00
. if not then what is the difference between (1.working.days.from_now and 1.days.from_now)