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. -- Ryan Bigg On Tuesday, 15 March 2011 at 3:17 PM, Farski wrote: > 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. > > > > > > > On Mar 14, 9:56 pm, Ryan Bigg <[email protected]> wrote: > > 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. > > -- > > Ryan Bigg > > > > > > > > > > > > > > > > On Tuesday, 15 March 2011 at 7:18 AM, Farski wrote: > > > 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 > > > > > -- > > > You received this message because you are subscribed to the Google Groups > > > "Ruby on Rails: Core" group. > > > To post to this group, send email to [email protected]. > > > To unsubscribe from this group, send email to > > > [email protected]. > > > For more options, visit this group > > > athttp://groups.google.com/group/rubyonrails-core?hl=en. > > -- > You received this message because you are subscribed to the Google Groups > "Ruby on Rails: Core" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/rubyonrails-core?hl=en. > -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
