Hey, I just read the post "Time...days" and it got me thinking. time() and/or timeGetTime() reutnr the number of milliseconds from 1970, right? A few questions: When exactly does it count from, 12:00AM jan. 1st 1970? And I know timeGetTime() returns the millseconds in a long format. Wont the number of milliseconds pass the highest value that a long could store at some point in time. Let''s see, a long could hold up to about 2 trillion (when signed). The number of seconds so far should be around 1 trillion seconds (I think my calculations might be off) Anyway, my final question is wont this function become unusable after a certian amount of years pass? Maybe it''ll cause some kind of Y2K type problem in the future. What do you guys think

>> Wont the number of milliseconds pass the highest value that a long could store at some point in time <<

Indeed. It''ll overflow in the year 2038 I think.

- Muzzafarath

Mad House Software
The Field Marshals

Yeah, it is a problem. That is why I like using the quadword times found in VMS and Win32. I think they store times in 100ths of milliseconds since some insane time. When reading the documentation on the VMS quadword time I ran into a reference that basically warned the user that the quadword time would rollover some time around the year 36000 (5 digits), but Digital Equipment Corp promised to have the problem resolved by then.

=)

Tim

quote: When reading the documentation on the VMS quadword time I ran into a reference that basically warned the user that the quadword time would rollover some time around the year 36000 (5 digits), but Digital Equipment Corp promised to have the problem resolved by then.

Somehow Y36K doesn''t sound so scary

lntakitopi@aol.com - http://www.geocities.com/guanajam

If you are using that function to create a delay and fix your frame rate, then i recommend to use GetTickCount() or QueryPerformanceCounter()/QueryPerformanceFrequency()...

..-=ViKtOr=-..

Any particular reason why gladiator?

------------------------------
fclose(fp)
------------------------------

because it''s MY favorite...

GetTickCount() doesnt have the problem that timeGetTime() WILL have in the future by the return value being overflowed... and the QueryPerformanceXXX() is the most accurate of all...

DWORD timeGetTime(void); returns time in ms elapsed from Window start and NOT the time elapsed from 1970.
Check it!

Hmm, I just checked msdn online and it seems like that''s what it says, but I know I read somewhere that it counts from some time in the 1970s, and it appears that people here were agreeing with that as if they had seen it somewhere too.

Either way it appears that the value rolls over to 0 approximately every 49 days :o)

------------------------------
fclose(fp)
------------------------------

This is why the time functions use thier own type, time_t, instead of one of the integrals. By the time 2038 rolls around, time_t will be more than 32 bits, the epoch will have been pushed forward, or both.