Andrej,
Take a look at this message (and patch, you'll be happy to hear) posted by
Gilles around this time last year in response to my bug report about the
very same issue. This should do it for you. Good luck.
Bill Knox
Lead Operating Systems Programmer/Analyst
The MITRE Corporation
On Thu, 15 Jan 2004, Andrej wrote:
> Date: Thu, 15 Jan 2004 18:48:04 +0100
> From: Andrej <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Subject: [htdig] Startday bug?
>
> Hello,
>
> I'm using the startday variable to find files that are not older than 40
> days. Now, there is one file in the file system, which has been created
> on 10th Jan. 2004. ht://Dig can't find this file. Other files are from
> 2003, and they can be found, if the modification time in fs is not older
> than 40 days.
>
> When I set the startday value on 10, the file created in 2004 is found.
> Is it possible that there is a bug if a value in startday is containing
> a value that goes in the previous year?
>
> The query that I send to htsearch is:
> config=staging/de_press&endday=&endmonth=&endyear=&startday=-40&startmonth=&startyear=&matchesperpage=1000&words=%2A&sort=date&restrict=/press&exclude=sitemap&page=1
>
> The ht://Dig Version is 3.1.6
>
>
> Sorry about my english,
>
> Andrej.
>
>
>
>
> -------------------------------------------------------
> The SF.Net email is sponsored by EclipseCon 2004
> Premiere Conference on Open Tools Development and Integration
> See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
> http://www.eclipsecon.org/osdn
> _______________________________________________
> ht://Dig general mailing list: <[EMAIL PROTECTED]>
> ht://Dig FAQ: http://htdig.sourceforge.net/FAQ.html
> List information (subscribe/unsubscribe, etc.)
> https://lists.sourceforge.net/lists/listinfo/htdig-general
>From [EMAIL PROTECTED] Thu Jan 15 13:01:14 2004
Date: Wed, 22 Jan 2003 16:57:46 -0600 (CST)
From: Gilles Detillieux <[EMAIL PROTECTED]>
To: William R. Knox <[EMAIL PROTECTED]>
Cc: [EMAIL PROTECTED],
"ht://Dig mailing list" <[EMAIL PROTECTED]>
Subject: Re: [htdig] Bug in startday code, v. 3.1.6 (patched) (fwd)
According to William R. Knox:
> I am still seeing this problem, and have come across another clue. It
> works fine if a relative endday, such as -1, is also passed. In reading
> the bugs database closer, it also appears that bug 578570 may also be
> related.
>
> I have confirmed this bug by searching on the htdig site with the
> following three GET strings sent via a telnet session - note how the final
> two hit counts differ:
>
> Search for 'startday', no date range (returns 50 hits)
> ---
> GET /cgi-bin/htsearch?method=and&words=startday HTTP/1.1
> Host: www.htdig.org
>
> Search for 'startday', set startday to -60 (returns 0 hits)
> ---
> GET /cgi-bin/htsearch?method=and&words=startday&startday=-60 HTTP/1.1
> Host: www.htdig.org
>
> Search for 'startday', set startday to -60 and endday to -1 (returns 1 hit)
> ---
> GET /cgi-bin/htsearch?method=and&words=startday&startday=-60&endday=-1 HTTP/1.1
> Host: www.htdig.org
>
> Unfortunately, my C++ coding is non-existent, but the line which seems to
> me to be suspect is in Display.cc, line 1295-6:
> else if (!reldate)
> enddate.tm_year = endoftime->tm_year;
>
> Could this somehow be getting set to the same year as the
> startdate.tm_year?
... and on Tue, 7 Jan 2003 ...
> I believe that I have come across a bug in the startday code in version
> 3.1.6 (I have applied the metadate.0 patch and the timet_enddate.1 patch).
> Briefly, using a negative number in the startday that overlaps a year
> boundary (i.e. using a number greater than -7 today, 1/7/03) causes only
> entries for the previous year to be displayed. Here is an example:
Whoops! Mea culpa. When I added the support for relative dates, I
didn't realize that the added localtime() calls would clobber the data
structure that endoftime is set to point to. Surprisingly, this doesn't
affect all systems, but I guess some implementations of localtime share
the same return data structure as gmtime, and some don't.
Here's a fix, which I'll call timet_enddate.2, and which overrides
the timet_enddate.1 patch in the archives. It saves a copy of the
gmtime return structure so it's not clobbered. Plus it includes
Robert Marchand's earlier fix for the problem in 3.1.6's handling of
the end date in the date range support. (The test to see if the end
date was set was wrong, so htsearch assumed it always had to check
the date for each match, which caused the extra overhead described in
http://www.htdig.org/FAQ.html#q5.10)
Apply this patch in your main htdig-3.1.6 source directory using the
command: patch -p0 < this-message-file
If you've already applied timet_enddate.1, don't worry: the second hunk
of this patch will fail (because it's already been applied), but the
first should apply fine and all should work fine after that.
--- htsearch/Display.cc.orig Thu Jan 31 17:47:18 2002
+++ htsearch/Display.cc Tue Jan 21 15:46:19 2003
@@ -1148,6 +1148,8 @@ Display::buildMatchList()
// find the end of time
endoftime = gmtime(&eternity);
+ tm eterni_tm = *endoftime;
+ endoftime = &eterni_tm;
if(dategiven) // user specified some sort of date information
{
@@ -1407,7 +1409,7 @@ Display::buildMatchList()
// New check added on whether or not we need to check date ranges - MG
if (date_factor != 0.0 || backlink_factor != 0.0 || typ != SortByScore
- || timet_startdate > 0 || enddate.tm_year < endoftime->tm_year)
+ || timet_startdate > 0 || timet_enddate < eternity)
{
DocumentRef *thisRef = docDB.FindCoded(thisMatch->getURL());
if (thisRef) // We better hope it's not null!
--
Gilles R. Detillieux E-mail: <[EMAIL PROTECTED]>
Spinal Cord Research Centre WWW: http://www.scrc.umanitoba.ca/
Dept. Physiology, U. of Manitoba Winnipeg, MB R3E 3J7 (Canada)
