realbasic-nug
[Top] [All Lists]

Re: Microseconds rollover?

To: REALbasic NUG <realbasic-nug at lists dot realsoftware dot com>
Subject: Re: Microseconds rollover?
From: Phil M <phil at mobleybros dot com>
Date: Thu, 31 Aug 2006 14:49:17 -0700
Delivered-to: listarchive at realsoftware dot com
Delivered-to: realbasic-nug at lists dot realsoftware dot com
References: <416AE383-8C7E-4DCB-8C20-DE1CCDCFBDA4 at mobleybros dot com> <61C2F31C-C153-4998-91A8-E3F02F924EA3 at declareSub dot com> <EC8905A0-D1D5-41D5-BBEC-A9E73FFD4AEC at mobleybros dot com> <59B957F6-8AE0-4B7B-84E4-6E809F5F581A at shaw dot ca>
On Aug 31, 2006, at 2:16 PM, Terry Ford wrote:

There might be something else to consider. REALbasic may use a double to represent it but I have a strong feeling that the OS's storage of this data may be different. Take the Date Class for example. On Mac, the Total seconds are stored as an Uint32. This limits the Date to 2034 as far as I know. Also, on Win32, Microseconds is only resolved to milliseconds.

Perhaps this "Rollover" effect is something to consider as RS probably wouldn't mention it if it wasn't attainable.

That is exactly why I went looking.

It wasn't a problem when I was doing games... if the Microseconds rolled over, it would just force an early frame update. But now I am doing time measurement stuff, and I needed greater precision than Seconds.

Now a rollover for Ticks() is certainly plausible (1/60th of a second). The value returned by REALbasic is only stored in an Integer (signed), and so by my calculation it should rollover after 414 days.

_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>


<Prev in Thread] Current Thread [Next in Thread>