Does Anyone Know What Time It Is?

 

If you’ve ever written a unit test that failed only on Tuesdays, only after midnight, or only on CI but never locally, then congratulations — you’ve been personally victimized by DateTime.Now.

Time is one of those sneaky dependencies we rarely think about… until it breaks our tests.

Thankfully, modern C# finally gives us a first-class way to deal with time in a testable, civilized way:

👉 TimeProvider

Let’s talk about why it exists, why it matters, and how it makes your unit tests calmer, cleaner, and way less haunted.

---

🧨 The Classic Problem: Time Is a Liar

Here’s a pattern we’ve all written:

public bool IsExpired(DateTime expiresOn)
{
    return DateTime.Now > expiresOn;
}

Seems harmless, right?

Now try to unit test it.

• What time is it right now?

• What happens if the test runs at midnight?

• What about daylight saving time?

• What if the test is slow?

• What if it runs in a different time zone?

You don’t control time — time controls you.

---

🧠 Enter: TimeProvider

Introduced in .NET 8, TimeProvider is a framework abstraction for time itself.

Instead of your code reaching out to the system clock, time gets injected — just like logging, configuration, or databases.

Think of it as:

“Dependency Injection… but for time.”

---

🕰️ Basic Usage (The Right Way)

Production Code

public class SubscriptionService
{
    private readonly TimeProvider _timeProvider;

    public SubscriptionService(TimeProvider timeProvider)
    {
        _timeProvider = timeProvider;
    }

    public bool IsExpired(DateTimeOffset expiresOn)
    {
        return _timeProvider.GetUtcNow() > expiresOn;
    }
}

Registering in Production

services.AddSingleton(TimeProvider.System);

That’s it.
Your app still uses real-time — but your tests don’t have to.

---

🧪 Unit Testing: Freezing Time (Legally)

Now the fun part.

Create a Fake Time Provider

var fakeTime = new FakeTimeProvider
{
    UtcNow = new DateTimeOffset(2025, 1, 1, 12, 0, 0, TimeSpan.Zero)
};

var service = new SubscriptionService(fakeTime);

Write a Deterministic Test

[Fact]
public void Subscription_IsExpired_WhenDateIsInPast()
{
    var fakeTime = new FakeTimeProvider
    {
        UtcNow = new DateTimeOffset(2025, 1, 10, 0, 0, 0, TimeSpan.Zero)
    };

    var service = new SubscriptionService(fakeTime);

    var expired = service.IsExpired(
        new DateTimeOffset(2025, 1, 1, 0, 0, 0, TimeSpan.Zero)
    );

    Assert.True(expired);
}

No delays.
No sleeps.
No “wait and see.”
No flaky failures.

Just clean, predictable tests.

---

🧊 Advancing Time Without Waiting

Need to test retries, timeouts, or expiration logic?

fakeTime.Advance(TimeSpan.FromDays(30));

Boom.
Thirty days passed — instantly.

Your test finishes in milliseconds instead of minutes.

---

😌 Why This Makes Tests Better

✅ Deterministic

Tests behave the same every run.

✅ Faster

No Task.Delay, no waiting, no sleeps.

✅ Clear Intent

You declare what time it is. No guessing.

✅ CI-Friendly

Time zones, DST, and clock drift stop being your problem.

✅ Readable

Future-you won’t wonder why a test randomly fails in March.

---

🚫 What to Stop Doing

If you see this in new code:

DateTime.Now
DateTime.UtcNow
DateTimeOffset.Now

🚨 Pause. Breathe. Refactor.

Time is a dependency.
Treat it like one.

---

🎵 So… Does Anyone Know What Time It Is?

Yes.

Your test does.

And it’s exactly the time you told it to be.

---

🏁 Final Thought

TimeProvider isn’t flashy.
It doesn’t add features users can see.

But it quietly eliminates an entire class of bugs — the kind that waste hours, break trust in tests, and make developers mutter things under their breath.

And that’s the kind of improvement that really stands the test of time. 😉