SPAN query parameter can be mis-handled

[Darrin Smart]

We recently updated from 1.4.20 to 2.0.0 and have come across an issue with the SPAN term in Omega searches. Our search does not use START or END query parameters, just SPAN:

<select name="SPAN" id="daterange" onChange="form.submit()">
<option value="" $if{$eq{$cgi{SPAN},},selected}>Any time</option>
<option value="1" $if{$eq{$cgi{SPAN},1},selected}>Past Day</option>
<option value="7" $if{$eq{$cgi{SPAN},7},selected}>Past Week</option>
<option value="31" $if{$eq{$cgi{SPAN},31},selected}>Past Month</option>
<option value="365" $if{$eq{$cgi{SPAN},365},selected}>Past Year</option>
</select>

Searches would return results when "Any time" is selected but give zero results in other cases.

I suspect the issue might lie in xapian-omega/date.cc:

   250             time_t end = time(NULL);
   251             struct tm *t = localtime(&end);
   252             y2 = t->tm_year + 1900;
   253             m2 = t->tm_mon + 1;
   254             d2 = t->tm_mday;
   255             parse_date(date_end, &y2, &m2, &d2, false);
   256             int then = ymd_to_days(y2, m2, d2) - days;
   257             days_to_ymd(then, y1, m1, d1);

It looks like the call to parse_date() isn't meant to be here. Indeed removing it seemed to fix the problem for me.

[Olly Betts]

Thanks, I've pushed a fix with a regression test: fe8dcbb11216571cc374322281eca6911a0d6e1a

FWIW, this was causing the start of 1970-01-01 being using as the end of the range (but only when using terms for date filtering - value range date filtering was unaffected).

If I apply the test change to the tip of the RELEASE/1.4 branch it passes, which confirms that this is a 2.x only bug and there's no fix to backport but I've backported the improved test coverage: cd249777752db5d1b17d7d80abf16b3e596dfd53

(BTW, you might want to look at migrating to value-based date ranges - they should require storing less data, perform better, and allow finer granularity ranges; there isn't currently a plan to drop support for term-based date ranges, though you need to use omindex --date-terms to index the terms for them with 2.x.)

[Olly Betts]

This is actually present in 1.4.x since 1.4.27 too. I'll backport the fix for 1.4.32.