Design pattern for application time?

Question

If you build systems where business processes depend on what time it is^[1], you cannot use DateTime.Now or similar in your code, as you will have to deal in tests with e.g., future End Of Month or End Of Year scenarios. Changing the operating system time is generally not an option when you use SSL certificates and because it is complex to do correct for a distributed system.

One option is create a singleton service accessible by all systems that returns the current time. In production it could return DateTime.Now and in tests it could return a game time like 28th of February in a End Of Month scenario.

But is there better way of doing this? Like a more database oriented approach because it leads to better performance? Or would you put in a distributed cache? Is there some well-known design pattern for this?

^{[1] typical example: business processes implemented by insurance system, core banking system, ...}

Answer 1

One way to deal with this issue is to have a clock interface:

public interface IClock {
  DateTime Now { get; }
}

And use this interface throughout your code, in place of DateTime.Now. In production, you'll use its canonical implementation (or a UTC variant):

public class SystemClock implements IClock {
  public DateTime Now { get { return DateTime.Now; } }
}

You can, e.g., use SystemClock as a default in all classes that need IClock and allow other implementations to be injected through constructors or setters.

In tests, you can create a test implementation or mock it with a mocking framework.