I haven\'t tested this yet. I am hoping someone already knows the answer, so I don\'t have to write a test application, otherwise I will. :)
Usually when I want to c
I'll just quote Jim Mischel comments, as it's the most relevant answer to my question.
None of the timers depend on the system time. That is, the user changing the clock will not affect
System.Windows.Forms.Timer,System.Timers.Timer, orSystem.Threading.Timer. Nor will it affectStopwatchorEnvironment.TickCount. Also, there's no "overhead" to usingStopwatch. It's not like the value is continually updated. It's lazily evaluated (i.e.Ticksis updated when it's referenced).Documentation for Stopwatch says: "The
Stopwatchmeasures elapsed time by counting timer ticks in the underlying timer mechanism. If the installed hardware and operating system support a high-resolution performance counter, then theStopwatchclass uses that counter to measure elapsed time." If you look up info on the high-resolution performance counter, you'll see that it doesn't depend on the system timeTimers are similar.
System.Threading.Timeris based on Windows Timer Queue Timers. See that documentation. System.Timers.Timer is just a wrapper aroundSystem.Threading.Timer.System.Windows.Forms.Timeris a wrapper around the WindowsSetTimerandKillTimerfunctions. Documentation for those indicates that they are not dependent on the system time.
I was trying to solve similar problem. I turn out to use System.Diagnostic.StopWatch to replace all DateTime.Now. StopWatch will use the high frequency clock if present. So, it's more accurate and independent of the system clock change. However, if high frequency clock is not present, it will fall back to use system clock again.
According to my testing, all my machines have high frequency clock, including the machines in VM.
About the Timer, as far as I remember, it isn't dependent on the system clock. However, you don't really want to use Timer to track the time because the Timer callback events may be deferred by some other events.