Extensions: Should we move ISystemClock to Primitives?

[pranavkm]

We use it as a way for testing and have copies of that interface in multiple places

• https://github.com/aspnet/Caching/blob/dev/src/Microsoft.Extensions.Caching.Abstractions/Internal/ISystemClock.cs
• https://github.com/aspnet/KestrelHttpServer/blob/dev/src/Microsoft.AspNetCore.Server.Kestrel/Internal/Infrastructure/ISystemClock.cs
• https://github.com/aspnet/Security/blob/dev/src/Microsoft.AspNetCore.Authentication/ISystemClock.cs (this one is unfortunately public API)

I'm adding one to FileSystem to add testing support for polling. Should we commonize it Microsoft.Extensions.Primitives? That said, it's not a whole lot of code to replicate so there isn't a lot of benefit to commonizing it.

[pranavkm]

cc @Tratcher \ @Eilon

[Tratcher]

_shrug_ we keep talking about it but never found a reason to do it.

[Eilon]

Meh. It's so tiny we'd just be adding more spaghetti.

[natemcmaster]

The clock interface is always testing purposes. IMO unless we need different clock implementations at runtime, it doesn't provide value as an API.

[Eilon]

Yeah it's always just for testing. And it's like 10 lines of code. And it never changes.

[sebastienros]

Real world apps (see where I am looking at) need this abstraction. But because it's not in Primitives we'll have to do our own, like we did by the past.
Sad thing is that now there is a risk that some of the components in the application don't use the same abstraction and make some tests not possible.

[AceHack]

I would like this abstraction as well