Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!think.com!mintaka!bloom-beacon!LARRY.MCRCIM.MCGILL.EDU!mouse
From: mouse@LARRY.MCRCIM.MCGILL.EDU
Newsgroups: comp.windows.x
Subject: Re:  Does time go backwards from 10/24/90?
Message-ID: <9012200911.AA16917@Larry.McRCIM.McGill.EDU>
Date: 20 Dec 90 09:11:43 GMT
Sender: daemon@athena.mit.edu (Mr Background)
Organization: The Internet
Lines: 34

> Consider the following fragment from os/4.2bsd/utils.c:

> long
> GetTimeInMillis()
> {   struct timeval  tp;
>     gettimeofday(&tp, 0);
>     return(tp.tv_sec * 1000) + (tp.tv_usec / 1000);
> }

> By my calculations, this computation overflowed 32 bits about 7 weeks
> ago, since tp.tv_sec is a long (at least in my copy of SunOS).

What's the problem?  Yes, it overflowed; but so what?  (Note that it
wraps around every 0x100000000 milliseconds, which is roughly fifty
days.  You'd have to go back to February 19, 1970, in order to avoid
overflowing an unsigned 32-bit value, or January 25, 1970, for a signed
32-bit value.)  The exact value is unimportant; the server splits all
time (except for magic values like CurrentTime) into equally-sized
pieces called "past" and "future".

It is true that if GetTimeInMillis is used naively there is a bug
beause it can result in CurrentTime being used as a timestamp, but
there are only a few hazardous milliseconds each time the calculation
wraps around - one hazardous millisecond per special protocol value.
(The only special protocol time value that come to mind is
CurrentTime.)

In fact, depending on the system's clock (primarily the resolution
thereof), there may even be no hazardous times at all....

					der Mouse

			old: mcgill-vision!mouse
			new: mouse@larry.mcrcim.mcgill.edu