RFC Time#during? range testing method

The Time calculations were missing a nice, succinct way for testing if a time instance was during a specific period or range of times.

I came up with Time#during, which can take three forms of input:

# a range of Times Time.now.during?(Time.now.midnight..Time.now.tomorrow.midnight) # a Date Time.now.during?(Date.today) # or number values, like Time.utc(2011, 3, 14) # which will create the smallest possible range with given arguments Time.now.during?(2011) Time.now.during?(2011, 3) Time.now.during?(2011, 3, 14) Time.now.during?(2011, 3, 14, 16)

I think it's a very intuitive testing format, and fits in well with the rest of the Time calculations. Any thoughts?

working branch: https://github.com/farski/rails/tree/time_calculations_during

I would honestly prefer something less assumptive of the ordering of times, like Time.now.during?(:month => 2) That way you could just pass it “bits” of a time, rather than Time.now.during?(nil, 2), which is just ugly.

Other than that, I do like this idea.

So in the case of t.during?(:month => 2), would you want that to be true if the current date is in February, regardless of the year? I think that's what you mean when you say you want something less assumptive, but I'm not sure. To me that seems like just adding another way of saying: t.month == 2.

I suppose in cases where you're checking multiple, arbitrary time parts (like t.during?(:month => 2, :hour => 12)) it's a little easier to read, and a bit less typing (maybe?). But it's still just complete duplication of (t.month == 2 && t.hour == 13).

For me, this should be a way to easily make some really sensible comparisons, which are a pain to do now. Also, doing them now the long way is generally going to be from the context of the period or the range, and I think most people are used to doing things in the context of the given date in Rails.

I could maybe see some separate methods pop up to take care of what you're looking for though; I still think they'd be repetitive, but maybe they convenience would outweigh the redundancy. eg, Time.now.in? (:march).on?(:tuesday), or something like that. But idk, that could get cruft-y pretty quick.

First up: I think it would be best to add these extensions as a gem first, and if enough people would want them then they could be made available on core.

Yes, t.during?(:month => 2) or t.during?(:month => “February”) wouldn’t care about the year. We’re only telling it to care about the month, and that’s all it should care about.