Fix Activity Start Time Precision

[tarekgh]

#45111
#44354

The Activity class has a property called StartTimeUtc which report the starting time of the activity. Activity class existed for long time and users used to create it through the constructor new Activity(...). When running on .NET Core, we use DateTime.UtcNow to get the starting time. We do that because in .NET Core the DateTime.UtcNow is returned with high precision. When running on .NET Framework, we don't use DateTime.UtcNow because its accuracy is ~16ms which is not that precise. Instead we use a combination of Stopwatch and DateTime to calculate more precise time. Activity has internal method called GetUtcNow() which implemented for .NET Core by just calling DateTime.UtcNow and implemented for .NET Framework by using the Stopwatch and DateTime. Activity.StartTimeUtc just use GetUtcNow() to get the starting time.

In .NET 5.0 we have introduced a new type ActivitySource which allow creating and starting Activity objects through the public method StartActivity(...). But the implementation of this method always use DateTime.UtcNow for getting the starting time. That made the reported starting time on the .NET Framework not precise and users of the System.Diagnostics.DiagnosticSource package that shipped with .NET 5.0 started to notice that and caused problems in their trace reporting.

The fix here is, instead of having ActivitySource.StartActivity(...) calling DateTime.UtcNow, we are changing it to call Activity.GetUtcNow() which will make the reported time on .NET Framework more precise. This change has no real effect on .NET Core as Activity.GetUtcNow() there just calling DateTime.UtcNow.

[ghost]

Tagging subscribers to this area: @tarekgh, @tommcdon, @pjanotti
See info in area-owners.md if you want to be subscribed.

Issue Details

---

#45111
#44354

The Activity class has a property called StartTimeUtc which report the starting time of the activity. Activity class existed for long time and users used to create it through the constructor new Activity(...). When running on .NET Core, we use DateTime.UtcNow to get the starting time. We do that because in .NET Core the DateTime.UtcNow is returned with high precision. When running on .NET Framework, we don't use DateTime.UtcNow because its accuracy is ~16ms which is not that precise. Instead we use a combination of Stopwatch and DateTime to calculate more precise time. Activity has internal method called GetUtcNow() which implemented for .NET Core by just calling DateTime.UtcNow and implemented for .NET Framework by using the Stopwatch and DateTime. Activity.StartTimeUtc just use GetUtcNow() to get the starting time.

In .NET 5.0 we have introduced a new type ActivitySource which allow creating and starting Activity objects through the public method StartActivity(...). But the implementation of this method always use DateTime.UtcNow for getting the starting time. That made the reported starting time on the .NET Framework not precise and users of the System.Diagnostics.DiagnosticSource package that shipped with .NET 5.0 started to notice that and caused problems in their trace reporting.

The fix here is, instead of having ActivitySource.StartActivity(...) calling DateTime.UtcNow, we are changing it to call Activity.GetUtcNow() which will make the reported time on .NET Framework more precise. This change has no real effect on .NET Core as Activity.GetUtcNow() there just calling DateTime.UtcNow.

Author:	tarekgh
Assignees:	-
Labels:	area-System.Diagnostics.Tracing
Milestone:	-

[tarekgh]

@ericstj @tommcdon this is the issue that I talked to you about and going to ask to port it to the servicing release. could

@sywhang could you please have a look as @noahfalk is off?

CC @cg110 @cijothomas

[tarekgh]

/backport to release/5.0

[github-actions]

Started backporting to release/5.0: https://github.com/dotnet/runtime/actions/runs/382236457

[sywhang]

LGTM!

[tarekgh]

The CI failure is unrelated and tracked by the issue #44306