[comp.windows.x] Does time go backwards from 10/24/90?

andy@nthropy.UUCP (Andy Lowe) (12/14/90)

Fellow Server Hackers:

Please forgive me if I'm missing something obvious, but...


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);
}

gettimeofday() returns seconds since 1/1/70 GMT 


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

(Notably, tp.tv_sec is declared unsigned long in my copy of AIX 3.1,
but is signed in my copies of ISC and SCO unix.)

Please responsd via e-mail, if you can shed some light on this for me.


Thanks, and regards

Andy Lowe
andy@nth.com

mouse@LARRY.MCRCIM.MCGILL.EDU (12/20/90)

> 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