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 rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
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 rubyonrails-core@googlegroups.com. > To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. > 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 rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
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 <radarliste...@gmail.com> 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 rubyonrails-core@googlegroups.com. > > To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. > > 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 rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
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 <radarliste...@gmail.com> 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 rubyonrails-core@googlegroups.com. > > > To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. > > > 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 rubyonrails-core@googlegroups.com. > To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. > 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 rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.