Environment.TickCount - can I trust the documentation?

[Guest]

The documentation states that Environment.TickCount is a signed integer that resets to zero on an overflow condition (after 24.9 days; i.e. its value goes from 0x7FFFFFFF to 0x00000000); and is never negative (the MSB is never set)

I've googled and seen an assertion that the documentation is wrong

http://groups.google.com/[email protected]&rnum=

The poster asserts that TickCount will wrap to Int32.MinValue after 24.9 days, i.e. its value goes from 0x7FFFFFFF to 0x80000000 (Int32.MinValue) like the underlying platform SDK API GetTickCount()

Can anyone give me a definitive answer to this? I looked at the IL for Environment.TickCount and didn't find code like "GetTickCount() & 0x7FFFFFFF" which would confirm the documentation is correct

I want to measure elapsed time in a server application which will, I hope, run for more than 24.9 days. I can't use DateTime because I need to measure intervals reasonably accurately even if the time is changed

If the documentation is correct, I can measure elapsed time something like

int startTime = System.Environment.TickCount
.... do something that takes considerably less than 24.9 days ..
int endTime = System.Environment.TickCount
int elapsedTicks
if (startTime < endTime

elapsedTicks = Int32.MaxValue - startTime + 1 + endTime

els

elapsedTicks = endTime - startTime


Incidentally it would be nice if Microsoft would add a static method to the Environment class to measure elapsed ticks (modulo 24.9 days). This would make my code much simpler and independent of how TickCount wraps around

int startTime = System.Environment.TickCount
int elapsedTicks = System.Environment.TicksSince(startTime)

Joe

 

[Niki Estner]

I'm not that good at binary maths, but wouldn't "(endTime - startTime) &
0x7FFFFFFF" give you the correct result anyway?

Consider using the QueryPerformanceCounter/-Frequency-API (I think you'll
need PInvoke to use it).

And, if you want simplicity, create a class that takes the start time in the
constructor and returns the elapsed time in a conversion operator! Something
like:
MyTime x = new TakeTime();
...
elapsedTime = x;

Niki

The documentation states that Environment.TickCount is a signed integer

that resets to zero on an overflow condition (after 24.9 days; i.e. its
value goes from 0x7FFFFFFF to 0x00000000); and is never negative (the MSB is
never set).

I've googled and seen an assertion that the documentation is wrong:

http://groups.google.com/[email protected]&rnum=1

The poster asserts that TickCount will wrap to Int32.MinValue after 24.9

days, i.e. its value goes from 0x7FFFFFFF to 0x80000000 (Int32.MinValue)
like the underlying platform SDK API GetTickCount().

Can anyone give me a definitive answer to this? I looked at the IL for

Environment.TickCount and didn't find code like "GetTickCount() &
0x7FFFFFFF" which would confirm the documentation is correct.

I want to measure elapsed time in a server application which will, I hope,

run for more than 24.9 days. I can't use DateTime because I need to measure
intervals reasonably accurately even if the time is changed.

If the documentation is correct, I can measure elapsed time something like:

int startTime = System.Environment.TickCount;
... do something that takes considerably less than 24.9 days ...
int endTime = System.Environment.TickCount;
int elapsedTicks;
if (startTime < endTime)
{
elapsedTicks = Int32.MaxValue - startTime + 1 + endTime;
}
else
{
elapsedTicks = endTime - startTime;
}


Incidentally it would be nice if Microsoft would add a static method to

the Environment class to measure elapsed ticks (modulo 24.9 days). This
would make my code much simpler and independent of how TickCount wraps
around:

 

[Willy Denoyette [MVP]]

The doc's are wrong, so the value will be negative for 24.9 days out of
every 49.8 days.
Microsoft is aware of this and will correct the doc's, don't know when this
will surface.

Willy.