TIME() can vary slightly from SECONDS()

[dbMark]

While running one of my test programs, the duration counter reported negative time. Puzzled as to how I could have miscoded my app, I checked and rechecked but found nothing wrong. So I wrote a test line of code and sure enough it "fails" about once every 5-20 tries when in the last 1/10 second. I'm using VFP 9.0 SP1. (No, we haven't moved up to SP2 yet, not my call.)

? TIME() +" -- "+ STR(SECONDS(),9,3) + IIF(SUBSTR(TIME(),8,1)<>SUBSTR(STR(SECONDS(),9,3),5,1),"time error!","")

I'm thinking TIME() must be doing some rounding up internally to the next second. Within my code it seemed the TIME function was a little slower then the SECONDS function, not incrementing to the new second soon enough, but in the command line test it seemed the TIME function was rounding up to the next second about 18 milliseconds too soon. So I guess I'm confused a bit as to what really is happening here.

Upon further testing, it seems that in a program loop TIME() has already updated to the next second once SECONDS() reaches nnnnn.982 (sometimes?) or nnnnn.988 or nnnnn.997. From the command line it seems to be as soon as SECONDS()=nnnnn.909.

So you need to be careful not to take a shortcut like I did and append just the fractional part of SECONDS onto TIME as I did here. You need to parse the rest of SECONDS.

myTime = TIME()+RIGHT(STR(SECONDS(),9,3),4) && may report wrong second/fraction combination

Initially I had larger discrepancies when I got my negative duration error but now I can't duplicate them. Not sure why. The only difference I can imagine is that code was accessing objects. Also, I noticed that if I made my test code longer, such as a second set of loops after the first loops, there were no errors detected. It did not make a difference whether I checked TIME() first or SECONDS() first.

 

[dbMark]

I meant to write that this seems to affect the last 1/60th of a second, not 1/10th.

 

[DSummZZZ]

MS only knows how often VFP polls the system clock.
I ran this little test:

FOR zzz = 1 TO 1000
   ?TIME(1), SECONDS()
NEXT

And about half the time, the two were different.


-Dave Summers-

Even more Fox stuff at:

http://www.davesummers.net/foxprolinks.htm

 

[dbMark]

Yes, time does a function to display down to the hundredths and the docs do say it can vary by up to 1/18th of a second. I guess that leaves me with just this... dont intermix the the two functions or time comparizons may fail. When timing, use one or use the other.

 

[Mike Lewis]

DBMark,

Keep in mind that the computer's internal clock has a resolution of 55 ms (which works out at about 1/18 of a second). Basically, this means that you can't accurately time events that occur within the 55 ms window.

By the way, this has nothing to do with the processor's frequency. It is just the way the internal clock works.

Mike



__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro tips, advice, training, consultancy
Custom software for your business

 

[mmerlinn]

When you call the TIME() and SECONDS() they are both starting at two slightly different starting points. The second call will not start until AFTER the first call is finished, thereby rendering two different results.

If they both started at the same exact time, one would expect them to return the same results. But when they start at two different times, it is reasonable to expect different results.

mmerlinn

http://mmerlinn.com

"We've found by experience that people who are careless and sloppy writers are usually also careless and sloppy at thinking and coding. Answering questions for careless and sloppy thinkers is not rewarding." - Eric Steven Raymond

 

[Olaf Doschke]

Time() and Seconds() don't have the same source of data. To ensure a milliseconds accuracy seconds() can only pull the second from the system clock. Milliseconds must come from elsewhere.

In fact the docs say: "For versions of Visual FoxPro running on Windows NT 4.0 or later, SECONDS( ) returns a resolution of 10 milliseconds." I doubt this is still true for XP or Vista, but indeed if you need a higher resolution use API calls and performance counters:

http://msdn.microsoft.com/en-us/library/aa373083(VS.85).aspx

But the leasson learned is true anyway: Choose one ore the other to compute time differences, but don't intermix.

Bye, Olaf.