Use the new TimeProvider API from .NET 8

[martintmk]

Instead of writing our own variant of IClock that allows mocking time in tests we can now leverage the TimeProvider API that will be introduced in .NET 8.

The TimeProvider will be also available in .NET Framework by referencing the new nuget package.

Until the package is ready we can just copy the implementaiton into Polly, mark all classes as internal and once the official package is ready expose ResilienceStrategyBuilderOptions.TimeProvider property.

Wit this approach we will be using unified time abstraction and also allow easy unit-testing of strategies working with time.

[github-actions]

This issue is stale because it has been open for 60 days with no activity. It will be automatically closed in 14 days if no further updates are made.

[egil]

I would also suggest that you use https://www.nuget.org/packages/Microsoft.Bcl.TimeProvider to use TimeProvider for all the .NET versions you are supported. It has been backported to support .netstandard 2.0.

[egil]

Btw. I have a few issues with Microsofts FakeTimeProvider implementation, which is why I have kept my own fake around. Basically, their version does not behave consistently depending on how far you advance time. So if you are planing to use their FakeTimeProvider, check out https://github.com/egil/TimeProviderExtensions#difference-between-manualtimeprovider-and-faketimeprovider which explains the problem.

[martincostello]

@egil - We flushed out a bug in preview 6, but otherwise we've not had an real issues with FakeTimeProvider which we've adopted in #1144, but thanks for the link.

The NuGet package is being used for the down-level frameworks in that PR, which will likely ship as a v8.1.0 once .NET 8 ships (as dotnet/extensions for 8.0.0 depends on us shipping our 8.0.0).

That also reminds me I need to update that PR to RC1 (I've been on holiday the last 2 weeks)...

[egil]

@martincostello yeah, the FakeTimeProvider works. I did contribute quite a bit to its design and code, but after a lengthy discussion, the dotnet extensions team decided on the current design, so I'm keeping my own ManualTimeProvider around.

In the latest release of ManualTimeProvider I also made it possible to auto-trigger timers one or more times. That can be useful if the timers are being created and will run in a different thread/async task. Without the auto-trigger feature, the test code doesn't deterministically know when a timer has been created and thus does not know when to advance time.

Great to hear .NET 6/7 versions of Polly will also use and support TimeProvider.

[egil]

@martincostello I just installed Polly v8 and I cannot see any places where I can provide a TimeProvider to Polly, which would allow me to replace it during testing.

Are you not allowing Polly users to provide a TimeProvider?

[martincostello]

TimeProvider will be exposed in a future release when we can depend on the 8.0.0 package - we didn't want to ship our 8.0.0 package with a dependency on a prerelease package.

You can follow #1144 for the changes to support TimeProvider.

[egil]

Ahh ok, that makes sense.

[martincostello]

We'll look to ship that change as soon as possible after .NET 8 RTM.