According to mike grommet:
> Ok, I know what my problem is with my funky times being returned
> by mktime. mktime is adjusting them +6 hours for my time zone.
>
> I've still got to figure out the functions to convert the user specified
> date into UTC
> instead of my local time. This should be relatively minor though.
Uhm, the fact that mktime was adjusting them for your time zone suggests
that it is converting local time to UTC, so I think that problem is
solved already!
> another issue I'm running into
> is that my test web server returns 0's for doctimes because
> I've got apache configured to parse every html document... is there anyway
> to force apache
> to go ahead and return the last modification date of the html document
> instead of returning 0 when it comes to parsed html?
Dunno about this. It seems when we talked about this back in February,
you were using CGI scripts to generate the output, and I found out that
you can make a CGI script output a Last-Modified header with the date you
want, and htdig will pick it up. Server parsed HTML is another matter.
> I know that sounds a bit silly since theoretically, every document
> could change every time it is viewed, but viewing doesnt change the document
> modification time...
It makes sense if the content doesn't change. Note, though, that if you
want the content to change, and browsers to pick up the new content, you
shouldn't monkey around with the last-modified date. Browsers use this
to determine whether the document needs to be reloaded. So does htdig!
> as an interesting fix for this, couldnt it be possible to assign
> a meta tag to go in the document header for the document date?
> How difficult could it be to add this, since htdig is already parsing the
> meta tags in the header anyway, right?
Take a look at how htdig-notification-date is currently handled.
You'd need to add similar code and similar fields in the docdb (and in
DocumentRef) to handle an additional date field, which you could encode
however you choose. You'd also likely want to add code to sort on this
new field as well, because the current date sorting sorts on modification
date, not meta dates. In short, it would probably take a lot of changes
to do this.
> Also, could you guys throw out some ideas on how to go about making
> the end date work for any size time_t?
>
> What I'm considering is to check the results coming back from mktime.
> if a date (either starting or ending) returns a -1 coming out of mktime,
> then I could use 0 for the timet_startdate if it was goofy
> and 1<<sizeof(time_t)*8-1 if timet_enddate is goofy.
That sounds like a good plan. Additionally, you may want to keep a flag
indicating if any of the start date fields are set, and likewise for the
end date fields. If none are set, use 0 or MAXTIME_T by default, and don't
bother plugging default values into the tm fields for conversion. By the
way, MAXTIME_T should be ((time_t) ~(1<<(sizeof(time_t)*8-1))), not the
number you wrote above, which I believe would give you a negative number.
--
Gilles R. Detillieux E-mail: <[EMAIL PROTECTED]>
Spinal Cord Research Centre WWW: http://www.scrc.umanitoba.ca/~grdetil
Dept. Physiology, U. of Manitoba Phone: (204)789-3766
Winnipeg, MB R3E 3J7 (Canada) Fax: (204)789-3930
------------------------------------
To unsubscribe from the htdig3-dev mailing list, send a message to
[EMAIL PROTECTED] containing the single word "unsubscribe" in
the SUBJECT of the message.
