: For reference, a related thread topic can be found here: : http://www.lucidimagination.com/search/document/2025d6670004838b/date_faceting_and_double_counting#2025d6670004838b ... : Was this done for a reason - are there any implications somewhere else
A major reason was mentioned in my econd reply to the thread you mentioned... http://www.lucidimagination.com/search/document/2025d6670004838b/date_faceting_and_double_counting#f9fa1b56803c68c4 ...we wanted to make sure the counts accurately represented what you would get if you then filtered on that date range -- and since the query parser only supported ranges that were inclusive on both ends we wound up with this. some improvements to the QUeryparser to support mixed use of [] and {} (ie: "date:[A TO B}") would help, but that leads to another small complexity... should we be inclusive of the lower or the upper? ... even if we make it an option, how should it apply to the "first" and "last" ranges computed? do the answers change if facet.date.other includes "before" and/or "after" should the "between" option be inclusive of both end points as well? ...lots of little nuances subtleties that ultimately lead to the decisiosn that for the time being it was simple, easy, and straight forward to just always be inclusive, and add support for more complexities later. In practice: people either don't notice, don't care, or find it easy enough to add/subtract 1 millisecond to their times to get the behavior they want. : If interested parties are in agreement, I can create an issue for it and the associated fix. If you can suggest some semantics for a new option to control the inclusion/exclusion of the endpoints on all of the various edge cases, that is straight forward and easy to understand, that would certainly be a nice addition. we can worry about the query parser aspect of filtering on those ranges later and people who want to use the new option at the expensive of being able to have consistent counts when filtering can turn it on. -Hoss
