This article explores the numeric precision of the ASP and VBScript Timer() function, outlining that it may be more accurate than it initially appears.
Prior to the arrival of PowerShell. The VBScript Timer() function wass the closest thing that script creators had for undertaking high precision timings in the Windows Scripting Host (WSH) environment.
The Timer() function returns a VBSingle – aka a Single Prevision floating point number or a “Real” – value as a representation of the systems real time clock. As a Single precision value, the permitted range is “-3.402823E38 to -1.401298E-45 for negative values; 1.401298E-45 to 3.402823E38 for positive values“. If you print out the value of Timer() in ASP/VBScript
You will get a value like
This value is a representation of the number of seconds that have elapsed on the local executing system since the local system click last hit midnight. Consequently, evaluating Timer() against a DateDiff() evaluation of the number of seconds since Midnight will result in the same answer (save for the decimal point).
WScript.Echo Timer() WScript.Echo DateDiff("s", #2019-07-01#, Now())
Which results in
The hidden detail
Masked in the 2 decimal places default printout. Timer() is significantly more detailed than just two decimal points. Depending on the precision of your systems Real Time Clock (RTC) the precision may be up to 7 decimal places. You can view your systems capability by subtracting the Integer from the timer value:
WScript.Echo Timer() - Int(Timer())
Which may result in a value such as
At 7 decimal places, the precision of Timer() is – floating point number inaccuracy side – considerably better than that of VBDateTime. Under VBDateTime, the second is the atomic value, offering no more precision.
0 - Second 0.6 - Decisecond / 1 tenth 0.61 - Centisecond / 1 hundredth 0.617 - Millisecond / 1 thousandth 0.6171 - 1 ten thousandth 0.61718 - 1 hundred thousandth 0.617187 - Microsecond / 1 millionth 0.6171875 - 1 ten millionth
This demonstrates that there is flexibility in VBScript for more precise clock operations. But is the resolution high enough?
The resolution and fidelity of the Timer() function is what makes it valuable (or not) to a programmer. On a modern system, with a High Precision Event Timer (HPET), the update interrupt will only fire so many times to update the clock.
Running an imprecise test as follows:
for i = 0 to 999 WScript.Echo Timer() - Int(Timer()) next
The output value only changed between 10 and 31 cycles (reflective of the CPU scheduler performing other tasks during execution. The counter incrementation was consistent, updating 48 times with an increment of between 0.0117187 and 0.0195313 seconds. Once every 20.8 cycles on average.
0.0195313 0.0195313 0.0195313 0.0195313 0.0195313 0.0195313 0.0195313 0.0195313 0.0195313 0.0195313 0.0195313 0.0195313 0.0195313 0.0195313 0.0195313 0.015625 0.015625 0.015625 0.015625 0.015625 0.015625 0.015625 0.015625 0.015625 0.015625 0.015625 0.015625 0.015625 0.015625 0.015625 0.015625 0.015625 0.0117187 0.0117187 0.0117187 0.0117187 0.0117187 0.0117187 0.0117187 0.0117187 0.0117187 0.0117187 0.0117187 0.0117187 0.0117187 0.0117187 0.0117187 0.0117187
In practice this means that the viable, comparable resolution of Timer() is not much better than once aver 0.2 seconds. Over a longer time period, Timer() can offer higher accuracy: provided you aren’t polling for an update more than every 0.2 of a second.