Date facet rounding bug
mihha - August 24, 2009 - 15:08
| Project: | Apache Solr Search Integration |
| Version: | 6.x-1.0-rc2 |
| Component: | Code |
| Category: | bug report |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | active |
Description
It seams that gaps are not calculated correctly.
If we have, for example, field with 2009-08-01T00:00:00Z, it will be listed twice - once in July 31, 2009 and again in August 1, 2009.
Yes, I know that there are very small chances for this to happen on node created and node changed dates, but I am using it for date cck field that has only date, so H:M:S is 00:00:00.
I am guessing that this can be solved if we move end range for one second? Just to figure out where should that be :)
Mihajlo
Kontrola
#1
#2
This issue currently has a duplicate with more information: #602836: Date facet by month returning results created outside that month
#3
Unmarking as duplicate. Sorry for the error.
#4
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
#5
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
#6
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.
#7
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);
?>