Provide an abstraction for the system clock

[lukepuplett]

Should we have a standard abstraction for the wall-clock that returns the local DateTimeOffset?

The idea is to break the hard dependency on the system clock and be able to inject a different clock for system level testing of time and ageing impacts, especially useful in finance.

I've rarely seen anyone do this but often seen people that wish they had. I think its just a habit we haven't learned yet.

If we saw more types taking IWallClock or whatever we'd maybe think more about this. Sure its super easy to implement but like ILogFactory life's better when we're all using a uniform interface.

[Clockwork-Muse]

Side note: Both Java (Clock - also has a timezone property) and NodaTime (IClock) have this, so the precedent is definitely there.

I feel like, instead of an interface or class, I want to have a delegate/func definition, but that's possibly just my fascination with functional languages talking. So something like:

public class SomeClass
{
    int SomeMethod(Func<DateTimeOffset> currentTime, int otherParameter);
    // To abstract getting the "system" timezone, if relevant.
    int SomeMethod(Func<(DateTimeOffset, TimeZoneInfo)> currentTime, int otherParameter);
}

// Used like:
var result = someClassInstance.SomeMethod(() => DateTimeOffset.UtcNow, 4);
var constant = someClassInstance.SomeMethod(() => new DateTimeOffset(2019, 4, 1, 15, 39, 0, TimeSpan.FromHours(0)), 4);

var result = someClassInstance.SomeMethod(() => (DateTimeOffset.UtcNow, TimeZoneInfo.Utc), 4);

...presumably, there'd be at least a "common" set of pre-defined clocks, for the system (probably provided by us?), as well as some other common use cases (fixed is trivial to create on your own if it's defined as a Func, but tick-every-n is slightly more complicated).

[vcsjones]

For what its worth this already exists in ASP.NET Core as ISystemClock. Personally I am not sold on this abstraction being in CoreFX since it's fairly easy for a developer to write themselves.

[danmoseley]

Sure its super easy to implement but like ILogFactory life's better when we're all using a uniform interface

Is it so common for unrelated components to want to share such an interface, that itis burdensome for it to be shared in some other common library? The fact that something might be interesting to have and possibly share is not enough by itself to add to the base libraries. There is a cost to defining and shipping a type and we may make a bad decision about its shape. Once we ship an IClock in .NET Core itself we essentially claim the name, even for ourselves if we want to try again with a different design.

[lukepuplett]

Valid points. I am not here to push my case, only to gather viewpoints.

A Func<DateTimeOffset> would work however, it requires a well-named parameter to communicate what the function should do, but maybe that's okay.

To avoid a function in a constructor or method signature, I think for many people it would mean writing a package that exports only a single public interface like IClock (to avoid taking a dependency on all of NodaTime e.g.)

But I'm open minded to people's thoughts, esp. contributors/maintainers.

[terrajobst]

Let's close this in favor of #36617 (because it has more comments)