Open mollerhoj opened 3 years ago
Sorry for my late reply, somehow I didn't get an email from this topic.
- We believe
since_date
should be inclusive anduntil_date
should be exclusive. See here for more details on why this is a good idea: https://stackoverflow.com/questions/9795391/is-there-a-standard-for-inclusive-exclusive-ends-of-time-intervals
I can see why [A, B)
is appealing. We decided to go with [A, B]
because this is how databases handle Ruby ranges by default. where(date: range)
will become WHERE data BETWEEN begin AND end
and is inclusive.
- I'm not sure about the
2012-02-01..2012-03-01
format. Is..
standard? We've been usingself.parse(start, end)
instead.
The ..
is standard for Ruby ranges:
> (1..2).to_s
=> "1..2"
split_to
is great - it looks like you've done the same thing within_groups_of
. Keep that name, it's better.
👍
- Support for finding the
intersection
of two date ranges, as well assubtracting
two date ranges could also be useful.
Great ideas, will work in those!
- Finally, you might want to consider allowing open ended date ranges. This is something we are about to implement. Having a notion of "All future days from this date" or "All past days from this date" can be very useful.
I've actually been working on this, you can see the progress in this PR: #5
I hope we can get this into ActiveSupport so we don't have to come up with our own classes all the time ;-)
We did the same and came up with a gem. I'm not sure how useful the DateRange is for every Rails app to make it into Rails Core. Have been discussing this with Rails core members.
In #6 you can find the intersection support. Subtracting is a bit more difficult, will look into that later!
Great! We'll work on replacing our own code with this gem, let's hope it becomes somewhat of a standard!
Can you maybe explain a bit further what the use case is for subtracting date ranges? There are many edge cases that might make this function not behave like expected. It might be a challenge to make sure these edge cases are handled correctly in the caller of the subtraction method.
It's useful in scenarios where we want to do calculations on date ranges as if they were sets. Operations such as union, intersection, subtraction, can be used to answer questions such as:
For union and intersection, I would expect a single range to be returned. For subtraction, guess an array of either 0, 1 or 2 ranges would make sense?
I'd suggest supporting different settings for inclusive/exclusive bounds: See postgres documentation: https://www.postgresql.org/docs/9.3/rangetypes.html
Should also affect to_s and inspect by printing either (),[],[) or (]
Hey, I just stumbed upon this. We have a very similar class in our code base - It might be helpful to look at some of the ideas we've been discussing:
1) We believe
since_date
should be inclusive anduntil_date
should be exclusive. See here for more details on why this is a good idea: https://stackoverflow.com/questions/9795391/is-there-a-standard-for-inclusive-exclusive-ends-of-time-intervals2) I'm not sure about the
2012-02-01..2012-03-01
format. Is..
standard? We've been usingself.parse(start, end)
instead.3)
split_to
is great - it looks like you've done the same thing within_groups_of
. Keep that name, it's better.4) Support for finding the
intersection
of two date ranges, as well assubtracting
two date ranges could also be useful.5) Finally, you might want to consider allowing open ended date ranges. This is something we are about to implement. Having a notion of "All future days from this date" or "All past days from this date" can be very useful.
I hope we can get this into ActiveSupport so we don't have to come up with our own classes all the time ;-)