milliseconds

[PCH]

I need to record the differences between 2 times.

minutes, seconds, milliseconds.

The datediff function cant return milliseconds, but i found the timespan
object can.

The problem is I cant seem to get a date/time value that actually has
milliseconds...

the Now call only has time to the second, even when i call now.millisecond,
it returns 0.

Any ideas?

Thanks.

 

[Alex Feinman [MVP]]

It's a limitation with CF. DateTime class has 1 sec granularity. You can use
Environment.TickCount to achieve better precision (at least 5-10 msec on
most devices)

 

[PCH]

Greet.

I tried the Environment.TickCount but the results seem way off. I could be
due to the emulator tho, I've found its time can be funky.

Ill run a test.. it will get the date, then get the environment tick count.
But the count doesnt make sense, it will be something like 80milliseconds.
and thats it.

Its supposed to be the total time from when the "pc" started.

My goal was to record the tickcount when the button is pressed.. then record
it again when its clicked again..then subtract the 2 numbers to get the
total ticks..turn that into a timespan..and get the correct minutes,
seconds, and milliseconds..

Even if i wait over a minute, the tickcounts are always so close together...

Any Ideas?

 

[Paul G. Tobey [eMVP]]

The tick count it *totally* unrelated to the current system time (doesn't
have a darn thing to do with it). You can't get the current time, append
the result of TickCount and expect that to represent the current time,
including the milliseconds. The TickCount result is good for measuring
differences (in units of ms). Get the TickCount at start and at end and
subtract them (once every xx number of days, you need to handle a roll-over
of the count).

That said, the TickCount in the emulator has been widely reported not to
work correctly. Try it on the actual device and it should be the number of
ms since the device was booted.

Paul T.

 

[Geoff Schwab [MSFT]]

Remember also that TickCount cannot be guaranteed accurate to a resolution
of greater than 500ms due to the nondeterministic nature of the framework.
I have found that it is typically much accurate than this - just not
guaranteed. As Paul mentioned, it has nothing to do with actual time,
rather it is the time in milliseconds since the device was turned on. It
also wraps so make sure your next time is not less than your previous time
to do a safe delta.

--
Geoff Schwab
Program Manager
Excell Data Corporation
http://msdn.com/mobility

This posting is provided "AS IS" with no warranties, and confers no rights.

 

[PCH]

That is exactly what I am doing. I think you are right that the emulator
ticks are way off.. ill have to setup a small test app to check it on the
real deal.

Thanks.

 

[PCH]

If it wraps, do you know the max # is hits at the wrap? I'd have to take
the diff from the first hit to that wrap point, and then add it to the new
position...

Thanks,

 

[Alex Feinman [MVP]]

Naturally it wraps at MAXINT = 2^31-1

If it wraps, do you know the max # is hits at the wrap? I'd have to take
the diff from the first hit to that wrap point, and then add it to the new
position...

Thanks,

 

[Paul G. Tobey [eMVP]]

I think that's 2^32 - 1, or 0xffffffff.

Paul T.

Naturally it wraps at MAXINT = 2^31-1

not

 

[Alex Feinman [MVP]]

The Environment.TickCount is int. It wraps at 0x7fffffff to x8000000 which
is int -(2^31-1)

 

[Paul G. Tobey [eMVP]]

Got it!

Paul T.

The Environment.TickCount is int. It wraps at 0x7fffffff to x8000000 which
is int -(2^31-1)

off.