How to use gettimeofday?
Post: #1
It would be sad if I couldn't even use the 'gettimeofday' function correctly. But I think I did something wrong. It will give you two values, in the struct timeval item:
Now, is tv_usec the time in microseconds since 1970, or the time in microseconds to be added to the time in seconds to form a more precise measurement?
Simple question, thanks.
Code:
struct timeval {
long tv_sec; /* seconds since Jan. 1, 1970 */
long tv_usec; /* and microseconds */
};Now, is tv_usec the time in microseconds since 1970, or the time in microseconds to be added to the time in seconds to form a more precise measurement?
Simple question, thanks.
Post: #2Code:
gettimeofday(&newtime,0);
mics = (newtime.tv_sec-oldtime.tv_sec)*1000000 + newtime.tv_usec - oldtime.tv_usec;
oldtime=newtime;mics = how many mics has passed between newtime and old time.
to answer your question:
Quote:or the time in microseconds to be added to the time in seconds to form a more precise measurement?
Post: #4
Ah, so *that's* why my code isn't working properly. *Feels stupid.* 
I also noticed that I accidentally put *did* in the title instead of *didn't*. *Feels more stupid.*
Thanks guys!
I also noticed that I accidentally put *did* in the title instead of *didn't*. *Feels more stupid.*
Thanks guys!
Post: #5
Just so you understand it better, the whole point of splitting it up like that is there isn't enough space in a 32 bit number to hold the number of microseconds since Jan 1, 1970, so in order to resolve it, they split it into seconds and microseconds. Eventually, they're going to need to either adjust the starting date or up it to 64 bit numbers as the number of seconds exceeds 2^32-1.
Post: #6
A signed int counting seconds since Jan 1 1970 will run out on
Tue Jan 19 16:14:07 NZDT 2038
according to Ruby...
An unsigned one will last as long again (to beyond 2100).
Tue Jan 19 16:14:07 NZDT 2038
according to Ruby...
An unsigned one will last as long again (to beyond 2100).
Post: #8
Makes me glad that I only use it for a relative time. (Unless somebody happened to play one of my future games right when it looses precision, which would be... quite interesting to watch as everything goes haywire) Of course they could pretty much transparently change it to unsigned, as long as people store the result in an unsigned int. (or only use gettimeofday for a relative time)
(Unless somebody happened to play one of my future games right when it looses precision, which would be... quite interesting to watch as everything goes haywire) Of course they could pretty much transparently change it to unsigned, as long as people store the result in an unsigned int. (or only use gettimeofday for a relative time)
Post: #9
An int on a 64bit system is still 32bits right? A long is 64? And a long on a 32bit is 32bits.
I think this is correct.
Please tell me if it's not.
I think this is correct.
Please tell me if it's not.
Post: #10Jones Wrote:An int on a 64bit system is still 32bits right? A long is 64? And a long on a 32bit is 32bits.
I think this is correct.
Please tell me if it's not.
This is true of Mac OS X and Linux, but not of Windows...
Possibly Related Threads...
| Thread: | Author | Replies: | Views: | Last Post | |
| gettimeofday discrepancy | JeroMiya | 2 | 2,369 |
Apr 24, 2007 10:48 PM Last Post: OneSadCookie |
|