On Wed, Feb 16, 2011 at 12:23, benhoyt wrote:
>
> > AFAIK, the Windows performance counter has long-term accuracy issues,
> > so neither is perfect. Preferably we should have a timer with the long-
> > term accuracy of time.time and the short-term accuracy of time.clock.
>
> Thanks for the tip --
> For example, are you assuming that your clock() call in logging is
> the very first call made?
Yes, we were making that assumption (the time.clock() call in the import of our
log module), which was true in our code, but I can see where it's not a good
thing to assume generally.
> Also, IIUC
> AFAIK, the Windows performance counter has long-term accuracy issues,
> so neither is perfect. Preferably we should have a timer with the long-
> term accuracy of time.time and the short-term accuracy of time.clock.
Thanks for the tip -- yes, I hadn't thought about that, but you're right,
Quer
On Wed, Feb 16, 2011 at 09:34, sturlamolden wrote:
> On 16 Feb, 15:30, benhoyt wrote:
>
> > It seems to me that the logging module should use a millisecond-accurate
> timestamp (time.clock) on Windows, just like the "timeit" module does.
>
> AFAIK, the Windows performance counter has long-term a
On 16 Feb, 15:30, benhoyt wrote:
> It seems to me that the logging module should use a millisecond-accurate
> timestamp (time.clock) on Windows, just like the "timeit" module does.
AFAIK, the Windows performance counter has long-term accuracy issues,
so neither is perfect. Preferably we should
On Feb 16, 2:30 pm, benhoyt wrote:
> It seems to me that the logging module should use a millisecond-accurate
> timestamp (time.clock) on Windows,
> just like the "timeit" module does.
It's not an unreasonable request, though I don't think logging should
be used to time things accurately. I'm a
> A simpler solution would be to caclulate the time it takes to the handle
> the request using time.clock() and include it in the log message.
> Something like:
Thanks, Ross. Actually, we are doing exactly that already -- it's how we
noticed the timestamp issue in the first place. However, that
benhoyt wrote:
>This works, but as you can see, it's a bit hacky. Is there a better way to =
>fix it? (I'd like the fix to affect all loggers, including the root logger.=
>)
A simpler solution would be to caclulate the time it takes to the handle
the request using time.clock() and include it in
The Python logging module calls time.time() in LogRecord.__init__ to fetch the
timestamp of the log record. However, time.time() isn't particularly accurate
on Windows. We're logging start and end of our requests in our web server,
which can be milliseconds apart, and the log timestamps often sh
