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: 
One way to deal with this issue is to have a [clock interface](http://martinfowler.com/articles/nonDeterminism.html#Time):

```
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.
For unit testing, you should be able to stub anything out, including the time. Some mocking frameworks (e.g. [Microsoft Shims](http://msdn.microsoft.com/en-us/library/hh549176.aspx)) allow you to override the behaviour of DateTime.Now.

For integration/system testing, what I've done in the past is use a configuration setting for each system component that specifies a DateTime offset for that component to use from the real DateTime. This could be set by an undocumented app.config setting, where if the setting is absent, normal behaviour applies. You'd need to be careful that this doesn't introduce any vulnerabilities however.