The current time looks like a value you can grab whenever you need it. In production code, it is really an external dependency—and treating it that way makes your business rules easier to trust and your tests far less fragile.

The clock is part of your application

DateTime.Now is convenient, which is exactly why it spreads. It appears in entities, validators, services, and background jobs before anyone stops to ask whether the code can be tested when the clock says something different.

That hidden dependency starts showing up at the worst possible time. A rule behaves differently on a server in another time zone. A test passes locally and fails just after midnight. A subscription that should expire “today” expires a few hours earlier than expected.

What direct access to the clock costs

  • Behavior can change between development, CI, and production environments.
  • Business rules become coupled to the server’s local time zone.
  • Tests cannot reliably move to tomorrow, next month, or two years ago.
  • Time-sensitive edge cases become difficult—or impossible—to reproduce.

How would you test a discount that closes at midnight? What about a free trial on its last day? If the code asks the operating system for the time directly, you are left waiting for the calendar to create your test data.

Inject the clock instead

Time is a dependency, just like a database or an email sender. Modern .NET gives you a built-in way to express that dependency: TimeProvider, available in .NET 8 and later.

Register the system clock once in your application’s dependency-injection setup:

builder.Services.AddSingleton(TimeProvider.System);

Then inject it into the service that owns the time-dependent rule. Prefer UTC for persisted timestamps and comparisons, and convert to a user’s local time only at the presentation boundary.

public sealed class TrialService(TimeProvider timeProvider)
{
    public bool IsActive(DateTimeOffset trialEndsAt)
    {
        return timeProvider.GetUtcNow() < trialEndsAt;
    }
}

Tests should control the date

Once the clock is injected, the rule no longer needs to know what day the test happens to run. A fake provider can place the application at an exact instant, so the boundary condition is explicit and repeatable.

var clock = new FakeTimeProvider(
    new DateTimeOffset(2026, 8, 30, 23, 59, 59, TimeSpan.Zero));
var trials = new TrialService(clock);

var trialEndsAt = new DateTimeOffset(
    2026, 8, 31, 0, 0, 0, TimeSpan.Zero);

Assert.True(trials.IsActive(trialEndsAt));

clock.SetUtcNow(trialEndsAt);
Assert.False(trials.IsActive(trialEndsAt));

FakeTimeProvider is available through the Microsoft.Extensions.TimeProvider.Testing package. The important part is not the package itself; it is that the test owns the clock and can move it deliberately.

What about older .NET versions?

If you are working on a framework version before .NET 8, the same design still applies. Define a small IDateTimeProvider interface, inject it, and provide a system-backed implementation in production plus a fake implementation in tests.

The API can differ. The principle does not: application code should ask an abstraction for the current time, not reach through to the machine’s clock.

A small change with a big payoff

Replacing scattered calls to DateTime.Now will not make every class better overnight. It will give your time-sensitive behavior a clear seam—one you can use to reason about time zones, reproduce failures, and test the awkward moments that matter most.

Same clock in production. Full control in tests. That is a dependency worth injecting.