On Apr 14, 6:09*pm, "Jim Cone" wrote:
The VBA Developers Handbook by Ken Getz states that the
Timer function "...can measure time only to 1/18 second
accuracy because of the particular internal timer it's
using."

A statement that is easily debunked by running the macro that I
provided.

1/18 seconds is about 55.556 msec, whereas I demonstrated that Timer
has a granularity of 15.625 msec (1/64 second), at least on Intel-
compatible MSWin XP systems.

(I suspect it true for all WinNT-based systems, which includes Win7
and Vista.)

Jim wrote:
Also, "It turns over as midnight, so if you happen to
be running a test over the bewitching hour, your test
results will be meaningless."

That gibes with the VBA Timer help page. And I confirmed it with my
own testing ;-).

It is true that GetTickCount does not suffer from that deficiency.
According to the GetTickCount "manpage", it rolls over about every
"49.7 days" -- actually about 49d 17h 2m 47.295s.

But note that that means GetTickCount will return a negative number
after about 24d 20h 31m 23.647s, since the VBA type is Long -- signed,
not unsigned as the system DWORD type is.

Probably not a concern for most users with personal computers. But
"always-on" shared and networked computers might be not rebooted
before then. At least, that is usually their goal.

In any case, the loss of precision can be significant in some cases of
time measurements.

I use Timer for quick-and-dirty time measures, being mindful not to
measure time across midnight ;-).

I use the QueryPerformance functions when I want precision, better
granularity or reliability.

Jim wrote:
Strangely, KB172338 states that the Timer resolution is
1 second vs. 10ms for TimeGetTime and GetTickCount.
(the summer intern strikes again).<g

I never take for granted anything that MS documentation states, at
least not when it comes to very technical details (timers, binary
floating-point, numerical boundaries and limitations of functions,
etc).