Re: Will this be true tomorrow?
hoesel@chem.rug.nl (frans van hoesel)
Errors-To: secret@www0.cern.ch
Date: Wed, 9 Feb 1994 12:48:23 --100
Message-id: <9402091145.AA00564@Xtreme>
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: hoesel@chem.rug.nl (frans van hoesel)
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: 1372
Chris told us:
[...]
> Hmm.. there's a point there, I guess. How about a compromise that doesn't
> cost too much: Adding the UNIX system time will not require any conversion,
> and it can easily be converted to all other file formats by remote analyzers.
> Local site users could have the convenient, readable local time, while
> tools would simply make use of the system time field.
>
> System time is a long integer, so it would cost another 8 bytes if printed
> in hex format. Yeah, this is an ugly format for humans, but easy to use
> by computers. ;-)
>
I would be happy if we had the choice, just as if you httpd would give
you the configurable output options that allow me to decide what to
log and what not (Hi roy:-), it would be ok with me is there were an
option te record the time in local or in gmt. everyadmin that decides
not log in GMT will no that the analyzer might run into problems, just
as if he decided not to log the name of the remote user, or whatever.
Tha's were the configurable output options are for, isn't it...
you can use them and create human readable output that contains all
the things you are interested in (and nothing more) (you can use
grep as you analyzer tool) or you don't use them and have some general
purpose analyzer read the log for you and produce out put in human
readable form (which might be local time!)
- frans