Does Stopwatch have a maximum time it can run?

Question

How long can the Stopwatch in .NET run? Does it wrap to negative or restart at 0 if it gets to that limit?

Answer 1

Stopwatch.Elapsed returns a TimeSpan. From MSDN for the MaxValue of TimeSpan:

The value of this field is equivalent to Int64.MaxValue ticks. The string representation of this value is positive 10675199.02:48:05.4775807, or slightly more than 10,675,199 days.

Answer 2

For managed code, the System.Diagnostics.Stopwatch class uses QPC as its precise time basis.

When QPC is available, which it always is on Windows XP or later.

How often does QPC roll over?

Not less than 100 years from the most recent system boot, and potentially longer based on the underlying hardware timer used. For most applications, rollover isn't a concern.

Acquiring high-resolution time stamps

Assuming Microsoft's Windows .NET implementation, this limit is hardware-specific and may be less than the size of a TimeSpan or a long as the other answers indicated. Still plenty large enough though. Good luck getting your program to run for 100 years!

Answer 3

StopWatch uses long data type whose max limit is -

9,223,372,036,854,775,807

So this is the max time(ticks) it can run.

Although it would take years to complete this time.

Answer 4

Stopwatch has an ElapsedTicks property (https://docs.microsoft.com/en-us/dotnet/api/system.diagnostics.stopwatch.elapsedticks), which has the following remark:

This property represents the number of elapsed ticks in the underlying timer mechanism. A tick is the smallest unit of time that the Stopwatch timer can measure. Use the Frequency field to convert the ElapsedTicks value into a number of seconds.

Stopwatch.Frequency is 10000000 on my system. Given the calculation long.MaxValue / Stopwatch.Frequency / 3600 / 24 / 365 results in 29247, that is 29247 (floored) years of 365 days (which obviously they aren't always, but I guess it's close enough).

I also checked the source of current .NET and reflected upon .NET Framework and both use a long field elapsed which it uses to keep track of the elapsed time in the paused state. However, in the running state it uses a startTimeStamp and diffs the current timestamp with the start timestamp and adds previously elapsed time from the elapsed field. However even if the current timestamp returned by the system would have overflowed this should still return the proper result, as long as total elapsed ticks (expressed in Stopwatch.Frequency units, not DateTime.Ticks) fits in a long.

Last but not least, in Stopwatch.Stop() there's a check if the elapsed value is negative and if it is it's reset to 0. There's a comment mentioning this is possible under certain circumstances (bugs in BIOS or HAL, according to the comment) when very small intervals are measured, but the same obviously applies when elapsed overflows and becomes negative.