Re: Will this be true tomorrow?

hoesel@chem.rug.nl (frans van hoesel)
Errors-To: secret@www0.cern.ch
Date: Wed, 9 Feb 1994 11:45:07 --100
Message-id: <9402091040.AA00466@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: 2987

Roy wrote:
> 
> > 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).

there is information lost! I have no idea what NZST is, I you had written
that time in your log file, then that logfile would have no meaning to me,
nor to any analyzer (except your local one). I I were to have a look at
your log with an analyzer then I need an extremely clever analyzer that
knows all the local time habbits correctly. You would also need to state
in your log file what NZST is.

> 
> > 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.

it is true! at least on all the unix boxes around. every unix machine
stores its time in GMT (not of ant interest to you as a human :-), and
when it displays the time for you, it does the conversion from GMT to your
local time. No big deal at all. You have a TIMEZONE variable once set on
your system to tell it how to convert from GMT to your local time.

[...] 
> 
> 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.
> 
as I said that conversion *is* needed eighter your deamon does it for you,
or your analyzer program. Why not keep think flexible and global and do
the conversion in the analyse phase?

> > 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.
> 
[fyi: the minus sign is there to subtract 

- frans