How to get precise DateTime in C#

Question

I know that DateTime.UtcNow does not have a relatively high degree of precision (10-15 ms resolution).

This is a problem for me because in my log files, I want better resolution for the purposes of resolving race conditions.

The question is: how can I get the current date/time with a better precision than what DateTime.UtcNow offers?

The only solution which I've seen up till now has been this: https://stackoverflow.com/a/15008836/270348. Is that a suitable way to solve the problem?

@Cole"Cole9"Johnson the OP mentioned that "I want a better resolution for the purposes of resolving race conditions" — Dan Drews
– Dan Drews, Commented Aug 15, 2013 at 17:18
You can't get better than 1 msec with timeBeginPeriod(), not nearly good enough for race conditions. Beware that just adding the logging already has a big effect on the race. You can make Stopwatch work. — Hans Passant
– Hans Passant, Commented Aug 15, 2013 at 17:20
You need to read this: Precision and accuracy of DateTime, Eric Lippert blogs.msdn.com/b/ericlippert/archive/2010/04/08/… — asawyer
– asawyer, Commented Aug 15, 2013 at 17:23
@RobSiklos You don't want to use that linked solution. Every time it gets reset your time can jump 10ms in either direction. That would completely destroy your ability to determine the relative time between logging calls. You just want a single Stopwatch that is never reset. — Servy
– Servy, Commented Aug 15, 2013 at 17:29

Servy · Accepted Answer · 2013-08-15 17:21:10Z

You can use Stopwatch for more precise measurements of time. You can then have each log entry record the time from the start of the first operation. If it's important, you can record the DateTime of the first operation and therefore calculate the times of the rest, but it sounds like just having the ticks/nanoseconds since the start of the first operation is good enough for your purposes.

Worth noting that Stopwatch drifts relative to wall clock time, so taking a DateTime.UtcNow on start-up and then adding a Stopwatch-derived offset will only work to produce timestamps that are "correct" relative to each other in the same system, not across systems. The accuracy will be quite poor over time (the Internet seems to think up to 0.2ms drift per second isn't uncommmon).

Alois Kraus · Accepted Answer · 2013-08-15 17:42:15Z

If you want to add tracing you could write your own ETW Trace Provider like here. Then you do not need to take care how the timing is fetched. The Windows Kernel will take care that the timing is accurate and the order of the events is correct.

If you do not want to write your own ETW Provider you can use EventSource which is available as Nuget Package which allows you to use it from .NET 4.0 as well. More infos has Vance Morrison on his blog.

When use ETW events then you get a powerful trace analyzer for free with the Windows Performance Toolkit. As added bonus you can do system wide profiling in all processes with minimal impact as well.

This allows you to selectively add call stacks for every event you write which can be invaluable when you want to track down who did call your Dispose method two times.

enter image description here

xanatos · Accepted Answer · 2013-08-15 17:32:17Z

Do you really need a precise timer or what you really need is something that give a sort? For example:

static class AutoIncrement { private static long num; public static long Current { get { return Interlocked.Increment(ref num); } } } Console.WriteLine(AutoIncrement.Current); Console.WriteLine(AutoIncrement.Current); Console.WriteLine(AutoIncrement.Current); Console.WriteLine(AutoIncrement.Current); Console.WriteLine(AutoIncrement.Current);

This is guaranteed to be unique, and to change every time, and to be sorted. Its precision is better than microsecond. Its precision is absolute on a single PC.

or if you really want Timestamps...

static class AutoIncrement { private static long lastDate; public static DateTime Current { get { long lastDateOrig, lastDateNew; do { lastDateOrig = lastDate; lastDateNew = lastDateOrig + 1; lastDateNew = Math.Max(DateTime.UtcNow.Ticks, lastDateNew); } while (Interlocked.CompareExchange(ref lastDate, lastDateNew, lastDateOrig) != lastDateOrig); return new DateTime(lastDateNew, DateTimeKind.Utc); } } } DateTime ac = AutoIncrement.Current; Console.WriteLine(CultureInfo.InvariantCulture, "{0} {1:yyyy/MM/dd HH:mm:ss.fffffff}", ac.Ticks, ac);

This last variant uses as a base DateTime.UtcNow, but each call if it isn't changed, it increments it by one.

@RobSiklos Something like this? Each call is guaranteed to give at least a +1 Tick on the previous one. The precision is still 10ms, but you can differentiate between the calls.
I'm not sure this works even on a single PC. The line you want to log runs in thread1, thread2 is switched to, a logged line is ran there, thread2 retrieves a number, thread1 is switched back to, it retrieves a number -> race condition (if you log before you run the line, a similar problem happens). The only thing Interlocked will guarantee is that no two entries will have the same number, but not that they won't get the numbers in the incorrect order. So you'd need to use locking to ensure a thread runs the line and retrieves a number without another thread being able to do it in between.
@svinja The only solution in that case is that the logger takes a lock on the timer and release it after having finished writing. Each other solution will have the same problem. And even then, what you'll have is the order of logging, not the order of operations.
You need to lock before you even run the line of code you want to log. lock -> run the line of code -> retrieve a number -> unlock. With this, I think you would always have the correct order. It doesn't matter whether you do the actual writing inside or outside the lock, you just have to retrieve the number inside the lock.

Collectives™ on Stack Overflow

How to get precise DateTime in C#

3 Answers 3

1 Comment

Comments

7 Comments

Linked

Hot Network Questions