DateTime.Now.Ticks question

  • Thread starter Thread starter Alain Dekker
  • Start date Start date
A

Alain Dekker

I've written this code:

long lStart = DateTime.Now.Ticks;
....
DoLongComplexTask();
....
decimal dElapsed = (((decimal)DateTime.Now.Ticks - (decimal)lStart) /
10000000.0m);
lbDiagnostic.Text = ("Time taken: " + dElapsed.ToString("0.000") + "s");

But all I ever get is one of these two:
"Time taken: 5.000s" or "Time taken: 6.000s"

no matter how many times I try. This is weird. Why nothing after the
seconds? I should have varying number of milliseconds, but it seems to be
rounded. Is this a coding bug or is there something like the GetTickCount()
I used to use in Delphi/C++ that I can use that is more accurate than
DateTime.Now.Ticks (which I note that documentation claims is accuracte to
100ns - not in my experience!).

I'm writing the application in VS 2005, targetting the CF .NET 2.0 on
Windows CE if thats relevant.

Thanks,
Alain
 
Alain said:
I've written this code:

long lStart = DateTime.Now.Ticks;
...
DoLongComplexTask();
...
decimal dElapsed = (((decimal)DateTime.Now.Ticks - (decimal)lStart) /
10000000.0m);
lbDiagnostic.Text = ("Time taken: " + dElapsed.ToString("0.000") + "s");

But all I ever get is one of these two:
"Time taken: 5.000s" or "Time taken: 6.000s" [...]
I'm writing the application in VS 2005, targetting the CF .NET 2.0 on
Windows CE if thats relevant.
Click to expand...

Maybe your platform has only an accuracy of one second of the absolute
time. This is not that uncommon, since many platforms do not support to
set the time to factional seconds.


Marcel
 
Thanks for the excellent responses. After digging around a bit more I
discover that:
a) The Stopwatch class is not implemented in the Compact Framework v2 (but
is in v4)
b) Windows CE does not (usually) allow millisecond resolution from the
DateTime class. Apparently this depends on how the OEM develops the OS and
is typical.

The solution is to use Environment.TickCount which does work on Windows CE
and the CF v2.

Thanks again!
Alain


Marcel Müller said:
Alain said:
I've written this code:

long lStart = DateTime.Now.Ticks;
...
DoLongComplexTask();
...
decimal dElapsed = (((decimal)DateTime.Now.Ticks - (decimal)lStart) /
10000000.0m);
lbDiagnostic.Text = ("Time taken: " + dElapsed.ToString("0.000") + "s");

But all I ever get is one of these two:
"Time taken: 5.000s" or "Time taken: 6.000s" [...]
I'm writing the application in VS 2005, targetting the CF .NET 2.0 on
Windows CE if thats relevant.
Click to expand...

Maybe your platform has only an accuracy of one second of the absolute
time. This is not that uncommon, since many platforms do not support to
set the time to factional seconds.


Marcel
Click to expand...
 
Hello,

I also think that System.Diagnostics.Stopwatch is the best solution.
Another way is to use TimeSpan as following:

long lStart = DateTime.Now.Ticks;

DoLongComplexTask();

TimeSpan tsElapsed = new TimeSpan(DateTime.Now.Ticks - lStart);

lbDiagnostic.Text = String.Format("Time taken: {0:f3}",
tsElapsed.Milliseconds / 1000d);
 
I've written this code:

long lStart = DateTime.Now.Ticks;
...
DoLongComplexTask();
...
decimal dElapsed = (((decimal)DateTime.Now.Ticks - (decimal)lStart) /
10000000.0m);
lbDiagnostic.Text = ("Time taken: " + dElapsed.ToString("0.000") + "s");

But all I ever get is one of these two:
"Time taken: 5.000s" or "Time taken: 6.000s"

no matter how many times I try. This is weird. Why nothing after the
seconds? I should have varying number of milliseconds, but it seems to be
rounded. Is this a coding bug or is there something like the GetTickCount()
I used to use in Delphi/C++ that I can use that is more accurate than
DateTime.Now.Ticks (which I note that documentation claims is accuracte to
100ns - not in my experience!).

I'm writing the application in VS 2005, targetting the CF .NET 2.0 on
Windows CE if thats relevant.
Click to expand...

It does not claim to have 100ns accuracy. It claims to use 100ns units.

Big difference.

Arne
 
I've written this code:

long lStart = DateTime.Now.Ticks;
...
DoLongComplexTask();
...
decimal dElapsed = (((decimal)DateTime.Now.Ticks - (decimal)lStart) /
10000000.0m);
lbDiagnostic.Text = ("Time taken: " + dElapsed.ToString("0.000") + "s");

But all I ever get is one of these two:
"Time taken: 5.000s" or "Time taken: 6.000s"

no matter how many times I try. This is weird. Why nothing after the
seconds? I should have varying number of milliseconds, but it seems to be
rounded. Is this a coding bug or is there something like the GetTickCount()
I used to use in Delphi/C++ that I can use that is more accurate than
DateTime.Now.Ticks (which I note that documentation claims is accuracte to
100ns - not in my experience!).

I'm writing the application in VS 2005, targetting the CF .NET 2.0 on
Windows CE if thats relevant.
Click to expand...

http://community.opennetcf.com/arti...ond-resolution-datetime-under-windows-ce.aspx

confirms that DateTime Now Ticks has a problem on Windows CE with
milliseconds.

If I read it correct then simply using Environment.TickCount may be good
enough for your type of measuring.

Arne
 
I also think that System.Diagnostics.Stopwatch is the best solution.
Another way is to use TimeSpan as following:

long lStart = DateTime.Now.Ticks;

DoLongComplexTask();

TimeSpan tsElapsed = new TimeSpan(DateTime.Now.Ticks - lStart);

lbDiagnostic.Text = String.Format("Time taken: {0:f3}",
tsElapsed.Milliseconds / 1000d);
Click to expand...

If the problem is that DateTime.Now does not contain
millisconds info, then TimeSpan will not solve the problem.

Arne
 
Yes, thanks Arne. I agree with your interpretation. I've tested
Environment.TickCount and it works well. Sure, there are limitations, but
its fine for what I need!

Thanks,
Alain
 
Good point! I admit to having being misled by that bit of
documentation...until now! I'll be using Environment.TickCount from now on.

Thanks very much.
Alain
 
Good point! I admit to having being misled by that bit of
documentation...until now!
Click to expand...

It is a "problem" that exist in most time returning functions.

They return an integer in some unit. But the actual granularity
is significant smaller.

There is a very good point in this.

The trend for computers is to get more fine clocks over time.

If units were granularity then the unit would have to change frequently
creating a very unstable API.

By having a very small unit the API can be constant for many years.

There is also a downside. You just found it.

Arne
 
Back
Top