Re: Will this be true tomorrow?

"Roy T. Fielding" <fielding@simplon.ICS.UCI.EDU>
Errors-To: secret@www0.cern.ch
Date: Wed, 9 Feb 1994 03:04:01 --100
Message-id: <9402081802.aa29359@q2.ics.uci.edu>
Errors-To: secret@www0.cern.ch
Reply-To: www-talk@www0.cern.ch
Originator: www-talk@info.cern.ch
Sender: www-talk@www0.cern.ch
Precedence: bulk
From: "Roy T. Fielding" <fielding@simplon.ICS.UCI.EDU>
To: Multiple recipients of list <www-talk@www0.cern.ch>
Subject: Re: Will this be true tomorrow? 
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
Content-Length: 3175

frans said:

> well, I short time ago there was some discussion about what the logfile
> was good for. I myself modified the deamon so it writes only as little
> info as possible, and exclude even the logs from my local host.

Yes, hacking the server works where configuration options don't.

> Others claimed that the log file should contain as much information
> as possible, so one could always decide afterwards what do save or
> examine from the log.

Yep, I said that.

> In order to do that you should not store the
> local time in your log file.

Why?  No information is lost when local time is stored -- it's not
as if the site is changing timezones (except for daylight <-> standard).

> Use GMT. most computer brands now
> have some kind of internationalization subroutines. one of the standard
> routines is presumably the routine that converts from GMT to local time!
> you analyzer program needs only to use such a routine and you are
> ready. besides you probably now how far away GMT is from your local time

I wish that were true.  It's not.  There are almost always routines to convert
from machine time to local time or GMT time.  There are almost always routines
to convert local time (in ASCII) to machine time.  Sometimes, there are
routines to convert GMT time to machine time (usually provided for NNTP).
The problem comes in determining what is the local timezone, for which
no portable solution exists.

FYI, I have no idea how far away PST is from GMT, but I'm sure I could
look it up somewhere.  But why should I when my world (and all my cares)
revolve around PST (and occasionally NZST).  I know that sounds rather
provincial, but it is nevertheless a fact of life.  I use GMT when interfacing
with programs, not with people. 

> I admit that all humans think in local time (including those in the
> Uk btw) but thinking in GMT is not too difficult eighter. besides
> that were you have your analyzer for. the cpu times spend are itrrelevant
> because if your analyzer doesn't do the conversion, then the logger has to!

It's a lot easier to think in GMT when your timezone is near GMT.
Personally, the only time I ever think in GMT is when I'm testing
HTTP server protocols via telnet.  If local time is stored in the log
and you want your web usage statistics printed in local time (as I do),
then no conversion is needed at all.  Even when you do want GMT, it's
much easier to go from local -> machine -> GMT than the other way around.

[I know, I should have put a smiley on that UK joke]

> ...
> 
> I cannot easely know what eastern standard time is, or arizona summer
> time or whatever local time you have. I do know what GMT -9.00 is!

Actually, I don't know what time that is (I could look it up in the 
rfc822 spec, but who wants to do that?).  The problem I always have is
remembering whether you add/subtract from the listed time to get GMT or
the listed time is GMT and you add/subtract the modifier to get the local
time (I suspect it's the latter).  Things get worse when the modifier
crosses over a date line.


...Roy Fielding   ICS Grad Student, University of California, Irvine  USA
                   (fielding@ics.uci.edu)