Date facet rounding bug

The problem I've posted about at #602836: Date facet by month returning results created outside that month is that the initial date range facet starts from the creation date of the first node:

<?php
    $start_iso = apachesolr_date_iso(db_result(db_query("SELECT MIN($facet_field) FROM {node} WHERE status = 1")));
?>

... which means that if the first node is created on the 15th of the month, the 15th day of the month will be the start date for all date faceting. When the date facet block displays links by month, the facet link will display 'September 2009', but the actual range the facet link will cover is from 15 September to 15 October.

I've attached a basic patch that calculates the initial start date for the date facet at the start of the year in which a node is created (since year is the largest discrete GAP for time), and the sets the end date as being December 31 for the year in which the most recent node is created. From testing using this patch the month, day, hour etc gaps should fall into place from there.

I hope this is useful.

Stuart

Attachment	Size	Status	Test result	Operations
558036_date_facet_range.patch	1.21 KB	Ignored: Check issue status.	None	None

Login or register to post comments

#5

Posted by mihha on November 22, 2009 at 2:21pm

I am not sure if these two bugs are connected... I've still didn't get chance to get into the code that is doing this so maybe I am mistaking...

I've tried stuzza's patch, but I am still getting the same issue (the same result is showing in two days).

Thing that is bothering me about patch is that minimal gap is one year (actually one year minus one second) and the original code can set minimal gap to less then that..

Mihajlo
Kontrola

Login or register to post comments

#6

Posted by jtbayly on December 10, 2009 at 3:11pm

Here is the problem. If you do a search for a date range, it is *always* going 1 second too far in the search. Meaning if you search for a node created in June you will sometimes show nodes created in July. As noted above this is rare for node creation timestamps, but as soon as you expand this to a CCK date field where a time isn't specified, every node has this problem.

If you search for a particular year, the first second of the next year is included, if you search for a particular month or day or even hour, the same thing happens. This manifests itself by showing improper search results for most date filters for us.

So a search for November 28 produces the following range:
from 2009-11-28T00:00:00Z TO 2009-11-29T00:00:00Z

The correct range (I think) would be:
from 2009-11-28T00:00:00Z TO 2009-11-28T23:59:59Z

When you are using CCK without a time, this means that searching for Nov 28 also shows all of the nodes marked with Nov 29.

Login or register to post comments

#7

Posted by robertDouglass on December 11, 2009 at 12:35pm

If #6 is the issue then I dealt with similar issues in the apachesolr_biblio module with code like this:

<?php
// Given some upper bound, non-inclusive,
$v = "1999 Mar 6";

// Make the date but shave a second off of it.
$date = apachesolr_date_iso(strtotime($v) - 1);
?>

Login or register to post comments

#8

Posted by jpmckinney on April 28, 2010 at 8:05pm

Status:

active

» fixed

Marking #602836: Date facet by month returning results created outside that month as not being duplicate. #4 applies to that issue, not this one.

The problem is that the $end_iso for one range should never equal the $start_iso for another range. If this constraint is violated, documents on the border will fall into two ranges, which is undesirable.

Fixed. Only applies to 6.x-2.x http://drupal.org/cvs?commit=360628