Re: Time parsing is wrong?

Henrick,

There is another relevant piece of trace:

        ...

MIME header. Date: Wed, 27 Jan 1999 17:07:58 GMT
MIME header. Server: Apache/1.3.1 (Unix)
MIME header. Last-Modified: Tue, 26 Jan 1999 15:32:09 GMT
MIME header. ETag: "3c000ac-16d4-36addff9"
MIME header. Accept-Ranges: bytes
MIME header. Content-Length: 5844
MIME header. Keep-Alive: timeout=15, max=100
MIMEParser.. Timeout after 15 secs
MIMEParser.. Max 100 requests pr connection
MIME header. Connection: Keep-Alive
MIMEParser.. HTTP/1.0 Keep Alive ignored
MIME header. Content-Type: application/x-jt
Building.... C-T stack from application/x-jt to */*
StreamStack. Constructing stream stack for application/x-jt to */*
StreamStack. Source output
Building.... Content-Decoding stack
StreamStack. Constructing stream stack for www/cache to */*
Format...... Wkd, 00 Mon 0000 00:00:00 GMT
Time string. Wed, 27 Jan 1999 17:07:58 GMT parsed to 917453278 seconds, or in
local time: Wed Jan 27 10:07:58 1999
Format...... Wkd, 00 Mon 0000 00:00:00 GMT
Time string. Tue, 26 Jan 1999 15:32:09 GMT parsed to 917361129 seconds, or in
local time: Tue Jan 26 08:32:09 1999
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Here local time is wrong.

Are there any definitions in config files on which computation of
timestring really depends? Maybe I have overridden them with old config
settings(?).

Becides in the old version of library (I ran test yesterday) the last-moidfied
string in metafile is off by one hour. Maybe in old version the conversiont of
wrong last modified time back to num of seconds and again to string gave another
offset and the result was right (+1 - 1 = 0). This stuff (which gives me errors
in new version) worked ok in old one.

In new version the last-modified time in metafile in correct, but conversion
gives the wrong result.

Thanks,

Olga.


On 27-Jan-99 Henrik Frystyk Nielsen wrote:
> At 10:15 1/27/99 -0600, olga wrote:
>>I have added code to HTTPReq.c to HTTPMakeRequest to get time zone and to
>>print the converted timestring:
> 
> I ran a test on solaris, linix, and digital unix - and there is a problem
> on solris but not on linux or digital unix. On solaris the lm date is one
> hour behind.
> 
> In older versions of solaris, there was a bug in the non-reentrant version
> of gmtime/strftime combination which is why there is the #ifdef SOLARIS in
> 
>       http://www.w3.org/Library/src/HTWWWStr.c
> 
> However, this is not the case anymore and in any case doesn't apply for SGI.
> 
> Henrik

----------------------------------
E-Mail: olga <olga@eai.com>
Date: 27-Jan-99
Time: 11:16:21

This message was sent by XFMail
----------------------------------

Received on Wednesday, 27 January 1999 12:29:42 UTC