Hi there,
I’m currently trying out Runt for a project at work where we want to
work out the number of ‘business’ hours that have occurred between two
dates. Using Runt I’ve found this super easy to express the working
hours but I’ve noticed there’s a bit of a performance hit to using
DateTime instead of Time. To start with I was using the following:
working_hours_expr = DIWeek.new(Mon) & REDay.new(9,30,17,30)) |
(REWeek.new(Tue, Fri) & REDay.new(9,00,17,30)
working_hours_expr.include?( DateTime.parse(event.created_at.to_s) )
If I tried to pass event.created_at straight into include?() it would
error with “undefined method `date_precision’ for Tue Nov 07 11:12:34
GMT 2006:Time (NoMethodError)”. I added the code below (which is
pretty much identical to the DateTime modification included with Runt)
and now it works (plus it’s a lot faster), but I’m wondering if
there’s any unintended consequences I should be looking out for? If
not, would it make sense to include this in the Runt gem?
class Time
include Runt::DPrecision
attr_accessor :date_precision
def date_precision
return @date_precision unless @date_precision.nil?
return Runt::DPrecision::DEFAULT
end
end
(Also, if anyone knows of a better way to work out how many business
hours have elapsed between two dates other than fast-forwarding
through the start and finish times whilst counting time within the
range I’m all ears.)
Cheers
Paul.