We wound up using SystemClock in our entities, and ISystemClock in DI-enabled services. I’ve never actually run into a test that fails because I forgot to reset SystemClock though, my tests always set up their own data.

The first is that I have to remember to replace the delegate with the original one (() => DateTime.Now) in all my tests. Setting and relying on static things in tests often leads to hard-to-track-down test failures, or even false passes.

The second is I actually prefer to know that my objects are relying on the system clock. Injecting ISystemClock into their constructors makes this obvious.

Yep, exactly! It’s an assumption that _every_ dependency resolver needs to be through dependency injection. I think global dependencies like this one are prime candidates for service location.

I really haven’t had a problem so far – I do have a Reset() method to reset the Now back to DateTime.Now. But if I’m testing behavior that uses SystemTime.Now(), I’ll have to do something with it, or the test will fail. The only thing not resetting will do is affect other tests. It won’t affect debugging, running locally or production, since those run in different AppDomains.

My implementation was a bit differrent as I’ve used an IClock interface (with one member Now) with two implementations Clock and StubClock but Clock (your SystemClock) also has a static member that lets you replace the instance. Same idea just a slightly different implementation (not sure I explained it well, no matter).

Only *slight* issue I’ve had is leaivng the DateTime in SystemClock behind in tests. My work around was to have a time_senstive_context_base and have it make sure we put back the real clock at the end. You doing something similiar?