Weird business_hours.ago result

[syntruth]

While this is not affecting my code, I noticed it while playing around while doing some brain storming on other stuff:

>> Time.now
=> 2016-03-31 11:15:08 -0400
>> 72.business_hours.ago
=> 2016-03-18 11:15:14 -0400

Using 3.business_days.ago works as expected.

>> 3.business_days.ago
=> 2016-03-28 11:15:21 -0400

[ghost]

This looks right to me if you assume 8 hours per business day gives 9 business days for 72 hours.

[bokmann]

This is an interesting edge case, relies on understanding the difference between business hours and business days, and my mind could be changed on this behavior. It might clear up some of the other open issues as well, but it is a change in semantics that might affect other people using them gem.

Today is a Saturday
Time.now
=> 2017-04-01 14:20:35 -0400

Three business days ago counts back on the date, but leaves the time the same:

3.business_days.ago
=> 2017-03-28 14:20:39 -0400

counting back by hours starts counting from the last worked business hour.

24.business_hours.ago
=> 2017-03-29 09:00:00 -0400

Notice the slight time difference is within the day/hour, and causes the day to be different between these two edge cases. I believe the day is right when the unit you care about is days, but the hour is right if you care about hours. Here's why:

The difference is best illustrated by considering edge cases. imagine a Friday where work stopped at 5pm. It's now 5:01pm on that very same Friday. When is one work hour ago? seems like 4pm to me. When is one work day from now? 9am today doesn't feel right for the colloquial use of this term.

The difference comes down to the answer to the question, "Do events that happen between 5pm on one business day and 9am the next business day, count as happening at 5pm that day or 9am the next day? Your environment may make a different assumption then the one in the environment where this gem was designed. Perhaps that needs to be a configuration option.