Re: time_t, ms_t, overflow issues

On 21 Nov 2001, Phil Nitschke wrote:

> Hi all,
>
> With many architectures still implementing an ms_t in a 32-bit integer,
> isn't HTGetTimeInMillis() going to suffer fairly badly from arithmetic
> overflow?
>
>     struct timeval tp;
>     gettimeofday(&tp, NULL);
>     return(tp.tv_sec * 1000) + (tp.tv_usec / 1000);
>
> (This message was written about 1006328788000 milliseconds after Epoch.)
>
> Given that, can any of the code in HTDoConnect() that calls
> HTDNS_updateWeigths() be trusted?
> Similarly, won't there be problems with other code that uses ms_t?
>
> Why does the HTNet structure need a connecttime field?  Isn't it asking
> for trouble to have a time_t connecttime field when the HTHost structure
> has a similarly named field implemented as a ms_t?
>
> (I search the archives, but could not fund these topics being discussed
> before.)
>

This problem was discussed on several systems mailing lists. And that's
the right point to discuss about that. It is the operating systems part to
implement gettimeofday in a way that the result fits into the data fields.
Of course if you put that numbers into a new one you have to count your
bits. To display a 32bit time_t in milliseconds we need a value which
is 1000 times bigger. That are about 10 bits. So we need about 42 bits.

But is it really usefull to calculate with such values ? Results in
quantum mechanics have up to 15 good digits in very common experiments
like the speed of light. If you are searching an ant you won't look at
satellite images, but you will take a magnifing glass that concentrates
your angle of sight to the near surroundings of the ant.

If you want to measure time in milliseconds you should only be interested
in an interval a few seconds before or after the point where you call get
time in millis. I've tried these behaviours once with the good old time_t
moving it through some centuries:

	Lets think about two points on a time axis far away from each
other. We call these points A and B. Now we want to calculate B-A
(with B>A). You can say of course the times A and B are C seconds (or
milliseconds) away from each other. But if C is too big this makes not
much sense to a human being: C=5.1235395835*10^18 ms ? hugh ? what's that
?
A year is about 86400 seconds -> 8.64*10^7 ms ->
	A is about 1/20 a billion(10^12) years away from B ( I hope I'm
right but it doesn't really matters ! ) But what if we want to be woken up
at a Saturday in the 30th week at 8:30 and 5 ms in 1/2 a billion years.
Hey man that makes sense ! A little bit more than to be woken up
5.12243535*10^18 ms from now.

It is all a matter of focus. If I write programs I always use time_t and
struct tm together. If time_t overflows thats no problem since I can use
the tm structure to restore the lost digits if I know where the point of
overflow is on my time axis. And if I want to calculate a timeout ( which
is the purpose on the milliseconds scale ), will first control if the two
points of time lie more than one hour away from each other. I just have to
select an upper border !!!

If you care for the scale on which you look at a problem, you will get
enough digits from HTGetTimeInMillis to express your results. And if your
really need the age of Napoleon in milliseconds you should express it as
x hours and y milliseconds.

CU INGO

Received on Wednesday, 21 November 2001 20:02:07 UTC