formatting time as milliseconds in logging module

[Josiah Carlson]

bokr at oz.net (Bengt Richter) wrote:

> Yes I suspected as much. You are presumably referring to

[snip original C source]
Yes.


> which IMO really should be (untested):
> -----------------
[snip unchanged code]
> 		divisor = (double)freq.QuadPart;
>                 now = ctrStart;
> 	} else {
> 		QueryPerformanceCounter(&now);
> 	}
> 	diff = (double)(now.QuadPart - ctrStart.QuadPart);
> 	return PyFloat_FromDouble(diff / divisor);
> -----------------

That would be arbitrarily more accurate, but on my machine it is a
difference of around 10^-5 seconds.  I don't think it really makes a
difference.

Feel free to submit a patch.

In the context of the original question, the poster would likely be
rounding to the nearest 1/1000 second, so the tens of microseconds
doesn't seem to be a concern.


> >> Maybe not even all windows. E.g., for NT that is one scheuling time slice,
> >> but oher variants might have other granularity, IWT.
> >
> >Good point, though I think that 9x variants also had .01 second
> >resolution.
> I don't recall, but the old ~55ms tick was used a lot in the old days.

According to a few sources, windows 98 time slices were around 20ms. 
Whether or not you could get time resolution beyond the time slice with
time.time(), let us find out.  I just happen to have a P166 running
windows 98...

Hrm, looks like 18 or 19 unique times each second, which is around the
55ms tick time you offer.  Ick.

 - Josiah