On Mon, 24 Sep 2001, Gilles Detillieux wrote:
> htdump puts the text database in db.docs, not on the standard output.
Sorry,didn't read the docs....
> Well, I guess we didn't make your deadline. :-) Nothing with the
> 3.2 betas is really an emergency, though, especially if your fix works
> for you.
There's always a next week.
> However, the reason for the LOOSE_* formats is because some HTTP servers
> are pretty loose in the format in which they output dates. Some leave
> off the weekday and/or the timezone, neither of which we should really
> need to get the complete date, so we need to be flexible enough to allow
> these. The LOOSE_* formats are correct, and the tm structure given to
> strptime() is static, and therefore its fields have an initial value and
> not random garbage. So, I don't see an obvious bug anywhere.
Well, this server disn't (apache). This initial value is obviously set
to 01-01-1970.
> It's hard to say for sure that your strptime() is buggy. Have you
> ruled out a problem with timegm()? The date conversion is a two stage
> process. First, strptime() converts the string into a "tm" structure,
> then timegm() converts the tm struct into a time_t value. You end up
> with a time_t value of 0, which indicates a problem with one or the other
> stages of conversion, but without a trace print in between to show the
> intermediate tm values, it's hard to say for sure where the problem is.
> I believe the trace prints you showed in your earlier e-mail all end up
> doing a new conversion from the already 0 time_t to a new tm structure,
> and don't show the intermediate results of the conversion.
I will see if I can dig into the tm thingy.
> If the intermediate tm structure values are OK, the problem is in
> timegm(), and it would be useful to know the value of HAVE_TIMEGM on
> your system. On the other hand, if the tm structure values are wrong,
> it would point to a problem in strptime(), but it might help to know which
> tm fields are wrong, as well as the value of HAVE_STRPTIME on your system.
ok, will look into that.
--jesse
--------------------------------------------------------------------
J. op den Brouw Johanna Westerdijkplein 75
Haagse Hogeschool 2521 EN DEN HAAG
Faculty of Engeneering Netherlands
Electrical Engeneering +31 70 4458936
-------------------- [EMAIL PROTECTED] --------------------
Linux - because reboots are for hardware changes
_______________________________________________
htdig-dev mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/htdig-dev