Tick Rollback

[abhi2011]

Hey guys, 

I was thinking of Unix Epoch and the rollback in 2038 because of an overflow. My question directly relates to the tick rollback we have in servers which run for more that some 25 days. 

Unix Epoch uses a 32bit signed integer for time representation in seconds. And as far as I understand vb6 uses a 32 bit integer as well (the long datatype). So why does a tick rollback happen on servers when using GetTickCount after running the server for a number of days? 

And why did we ever use GetTickCount. Could we have used UnixEpoch and used the time we got as a base and increment it ever second on out own basis resyncing it ever day or hour or something? 

Edit: Get Tick Count is in milliseconds and Unix Epoch is in seconds that's why Epoch can go a long way while GetTickCount can't

[SpiceyWolf]

GetTickCount is fast and accurate. If you want to make a defense against it, add a call at the very top of the serverloop sub that resets all the variables that relate to gettickcount to 0 after such a big number(even if thats only a few ticks before crashing point) problem solved.

[abhi2011]

> GetTickCount is fast and accurate. If you want to make a defense against it, add a call at the very top of the serverloop sub that resets all the variables that relate to gettickcount to 0 after such a big number(even if thats only a few ticks before crashing point) problem solved.

How can GetTickCount be faster than incrementing UnixEpoch removing the fact that we would have to resync the Epoch? And re-setting the variables to 0 won't work. The long data type is a signed datatype so it would reset back to negatives. -2^31 would be obtained.

Oh wait I Just found out the answer to my question. GetTickCount is in MilliSeconds while Unix Epoch is in Seconds lol.