I once spent hours chasing a flaky test that only failed on Mondays in CI. The root cause was simple: my test used the system clock, and the “current time” changed between assertions. That kind of bug doesn’t just waste time; it erodes trust in your test suite. Since Java 8, the Date Time API gives us a clean escape hatch: java.time.Clock. When I need time to stand still, I reach for Clock.fixed().
In this post I’ll walk you through what Clock.fixed() does, how it differs from other time sources, and how I use it to make time-sensitive code deterministic. You’ll see complete, runnable examples, common mistakes to avoid, and guidance on when to use fixed clocks (and when not to). If you build services that schedule tasks, calculate expirations, or log events across time zones, this method will save you real time and prevent subtle bugs.
Why a fixed clock matters in real systems
Time is one of the sneakiest dependencies in software. It looks harmless when you write Instant.now() or LocalDateTime.now(), but you’ve just coupled your code to an external, continuously changing source. That coupling creates issues:
- Tests that pass locally but fail in CI because the time changed between steps.
- Off-by-one date bugs around midnight, daylight saving transitions, or time zone boundaries.
- Race conditions when you capture “now” multiple times in one flow.
A fixed clock is like taking a photograph of time. Once captured, time doesn’t move. You can run your code over and over, and it will see the same instant every time. That’s the core promise of Clock.fixed().
When I’m testing logic like “expire after 30 minutes” or “only show items created today,” a fixed clock turns a risky external dependency into a stable, deterministic input.
The Java 8 Clock abstraction in plain terms
Java 8 introduced java.time.Clock as a replaceable time source. Think of it as the battery pack for your time API. Instead of calling Instant.now() directly, you can call Instant.now(clock) or pass a Clock into classes that need time.
Clock provides a few built-in factories:
Clock.systemDefaultZone()uses the system clock with the default zone.Clock.systemUTC()uses the system clock in UTC.Clock.fixed(Instant, ZoneId)returns a clock that never moves.Clock.offset(Clock, Duration)shifts time by a constant amount.Clock.tick(...)rounds time to ticks (useful for precision control).
The fixed() method is the one I use for testing. It returns a Clock that always answers with the same Instant and the same ZoneId.
Clock.fixed() signature, behavior, and guarantees
Here’s the method signature and what it means:
public static Clock fixed(Instant fixedInstant, ZoneId zone)
Parameters:
fixedInstantis the time you want to freeze. It must not be null.zoneis the time zone to associate with this clock. It must not be null.
Return value:
- A
Clockthat always returns the sameInstantand uses the providedZoneId.
Behavioral guarantees:
- The returned clock is immutable, thread-safe, and serializable.
instant()always returns thefixedInstant.getZone()returns the providedZoneId.withZone(...)returns a new clock with the same instant but a different zone.
I treat this clock like a constant dependency. It’s safe to reuse across threads or store as a static value in tests.
Example 1: Fixed clock with explicit time zone
This is the basic example. I’ll freeze time at a known UTC instant and associate it with an Asia/Calcutta zone. Notice how the output includes both the instant and the zone.
// Java program to demonstrate
// fixed() method of Clock class
import java.time.*;
public class FixedClockDemo {
public static void main(String[] args) {
// Fixed instant in UTC
Instant instant = Instant.parse("2018-08-19T16:02:42.00Z");
// Zone for Asia/Calcutta
ZoneId zoneId = ZoneId.of("Asia/Calcutta");
// Create the fixed clock
Clock clock = Clock.fixed(instant, zoneId);
// Print details of the clock
System.out.println(clock);
// Use the clock to produce date-time values
ZonedDateTime zoned = ZonedDateTime.now(clock);
System.out.println(zoned);
}
}
Expected output:
FixedClock[2018-08-19T16:02:42Z, Asia/Calcutta]
2018-08-19T21:32:42+05:30[Asia/Calcutta]
I like this example because it shows the instant is preserved, and the same instant maps to a local time based on the zone.
Example 2: Fixed clock using the default time zone
Sometimes you want to freeze “now” but keep the system’s default zone. This is useful when your app’s logic depends on local dates (billing cutoffs, daily reports, or start-of-day routines).
// Java program to demonstrate
// fixed() method of Clock class
import java.time.*;
public class FixedClockDefaultZone {
public static void main(String[] args) {
// Capture current instant once
Instant instant = Instant.now();
// Use the default system zone
ZoneId zoneId = ZoneId.systemDefault();
// Freeze time at the captured instant
Clock clock = Clock.fixed(instant, zoneId);
// Show the fixed clock
System.out.println(clock);
// Use it in LocalDateTime
LocalDateTime local = LocalDateTime.now(clock);
System.out.println(local);
}
}
Because instant is captured once, the output will always be consistent for the duration of the program run. That’s the key point: “now” is frozen at construction time, not continuously updated.
Example 3: Injecting a fixed clock into production-style code
A fixed clock is only useful if your code accepts a Clock dependency. I’m a big believer in constructor injection for time. Here’s a tiny service that calculates expiration timestamps.
import java.time.*;
public class TokenService {
private final Clock clock;
private final Duration ttl;
public TokenService(Clock clock, Duration ttl) {
this.clock = clock;
this.ttl = ttl;
}
public Instant expiresAt() {
// Use the injected clock instead of Instant.now()
return Instant.now(clock).plus(ttl);
}
}
And a simple test using a fixed clock:
import java.time.*;
public class TokenServiceTest {
public static void main(String[] args) {
Instant base = Instant.parse("2024-11-10T09:15:00Z");
Clock fixed = Clock.fixed(base, ZoneId.of("UTC"));
TokenService service = new TokenService(fixed, Duration.ofMinutes(30));
Instant expires = service.expiresAt();
System.out.println(expires);
// Expected: 2024-11-10T09:45:00Z
}
}
This is where Clock.fixed() shines. The test will always produce the same expiration instant, regardless of when it runs.
A simple analogy that sticks
When I explain Clock.fixed() to junior developers, I use a camera analogy. The system clock is a live video feed. A fixed clock is a snapshot. Both show “what time it is,” but only one stays the same from frame to frame. If your code compares two moments, you don’t want the camera moving while you measure.
That analogy makes it easy to see when you need a snapshot (tests, repeatable calculations) versus a live feed (runtime scheduling, real-time monitoring).
Common mistakes I see and how to avoid them
Over the years, I’ve seen the same time-related mistakes pop up in code reviews. Here’s how Clock.fixed() helps and what to watch for.
1) Capturing “now” multiple times in one method
Bad pattern:
if (Instant.now().isAfter(deadline)) {
// ...
}
If time moves between now() calls, you can get inconsistent results. Instead, capture once with a clock:
Instant now = Instant.now(clock);
if (now.isAfter(deadline)) {
// ...
}
A fixed clock forces you into the habit of single-capture logic.
2) Mixing time zones unintentionally
If you freeze time in UTC but compare it to local dates without converting, you can produce off-by-one day errors. Always decide which zone your business logic uses, then stick to it.
For example:
Clock fixedUtc = Clock.fixed(base, ZoneId.of("UTC"));
LocalDate utcDate = LocalDate.now(fixedUtc);
If your business rules are local, use the local zone instead. I prefer to pass ZoneId explicitly to avoid surprises from systemDefault() in tests.
3) Using a fixed clock in production unintentionally
This sounds obvious, but it happens in real systems. Someone adds Clock.fixed() in a service for a test and forgets to swap it back. To prevent this, I recommend creating your clock in a single configuration location and wiring it into services. In production, you use a system clock; in tests, you use a fixed clock.
4) Forgetting to test boundary dates
Fixed clocks let you test edge cases easily. If you don’t use them, you’re more likely to miss the edges around midnight, DST shifts, and leap seconds. I recommend a small suite of fixed instants that cover boundary conditions.
When I use Clock.fixed() vs when I avoid it
This is the rule of thumb I follow.
Use Clock.fixed() when:
- You are writing unit tests that depend on “now.”
- You need repeatable results for date calculations.
- You want to simulate a specific date/time in a deterministic way.
Avoid Clock.fixed() when:
- You need actual wall-clock time for scheduling, timeouts, or metrics.
- You want to measure real elapsed time.
- You’re implementing real-time monitoring or event streaming.
In production, I almost always use a system clock. In tests, I almost always use a fixed clock. That separation makes code clearer and reduces the chance of time-related bugs.
Fixed clocks and dependency injection: my preferred pattern
I recommend wiring time into your services the same way you wire a database or HTTP client. The simplest pattern is constructor injection with a Clock parameter.
Here’s a lightweight configuration example without any frameworks:
import java.time.*;
public class AppConfig {
public Clock clock() {
// In production, use real time
return Clock.systemUTC();
}
public BillingService billingService() {
return new BillingService(clock());
}
}
In tests, you override clock() with Clock.fixed(...). With a DI framework (like Spring), the same idea applies: you declare a Clock bean and swap it in test configuration.
This approach keeps time access consistent and avoids hidden calls to Instant.now() sprinkled around the codebase.
Traditional vs modern approach to time in Java
Here’s the comparison I usually share with teams migrating legacy code. It makes the benefit of Clock visible at a glance.
Modern approach
—
new Date() or System.currentTimeMillis() everywhere Pass a Clock and use Instant.now(clock)
Easy to test by injecting Clock.fixed()
Time zone behavior is explicit via ZoneId
More predictable with zone-aware APIsIf you’re still on the old APIs, Clock.fixed() is one of the best stepping stones into java.time.
Edge cases you should test with a fixed clock
A fixed clock is great for simulating tricky moments. I usually pick a few canonical instants for tests:
- Just before midnight in a local zone.
- The exact moment of a daylight saving “spring forward.”
- The exact moment of a daylight saving “fall back.”
- Leap day (February 29) in a leap year.
Here’s a quick example using a DST transition in New York:
import java.time.*;
public class DstEdgeCase {
public static void main(String[] args) {
// 2025-03-09T06:59:59Z is 1:59:59 AM in New York
Instant base = Instant.parse("2025-03-09T06:59:59Z");
ZoneId ny = ZoneId.of("America/New_York");
Clock fixed = Clock.fixed(base, ny);
ZonedDateTime zdt = ZonedDateTime.now(fixed);
System.out.println(zdt);
}
}
I use cases like this to verify that local date/time logic behaves correctly across transitions.
Performance considerations in real services
Clock.fixed() itself is lightweight. It just stores an instant and a zone. There’s no ticking, no system calls, no synchronization. In my experience, calling Instant.now(clock) with a fixed clock is effectively constant time with negligible overhead. In high-throughput services, I’ve seen typical time access in the single-digit microsecond range or lower, while system clock access can vary slightly depending on the platform.
What matters more is how you use time, not the clock type. If you call time APIs repeatedly inside tight loops or heavy streams, capture once and pass the value through. That reduces repeated conversions and keeps behavior consistent.
Real-world scenario: caching with fixed time in tests
Here’s a more complete example, showing a cache that expires entries after a TTL. This example uses a fixed clock in the test to ensure deterministic behavior.
import java.time.*;
import java.util.*;
public class CacheWithTtl {
private final Clock clock;
private final Duration ttl;
private final Map<K, Entry> store = new HashMap();
private static class Entry {
final V value;
final Instant expiresAt;
Entry(V value, Instant expiresAt) {
this.value = value;
this.expiresAt = expiresAt;
}
}
public CacheWithTtl(Clock clock, Duration ttl) {
this.clock = clock;
this.ttl = ttl;
}
public void put(K key, V value) {
Instant expiresAt = Instant.now(clock).plus(ttl);
store.put(key, new Entry(value, expiresAt));
}
public Optional get(K key) {
Entry entry = store.get(key);
if (entry == null) return Optional.empty();
Instant now = Instant.now(clock);
if (now.isAfter(entry.expiresAt)) {
store.remove(key);
return Optional.empty();
}
return Optional.of(entry.value);
}
}
A deterministic test:
import java.time.*;
import java.util.*;
public class CacheWithTtlTest {
public static void main(String[] args) {
Instant base = Instant.parse("2026-01-01T10:00:00Z");
Clock fixed = Clock.fixed(base, ZoneId.of("UTC"));
CacheWithTtl cache = new CacheWithTtl(fixed, Duration.ofMinutes(5));
cache.put("session-123", "active");
Optional first = cache.get("session-123");
System.out.println(first.orElse("missing"));
// Expected: active
// Simulate time passing by swapping the clock
Clock later = Clock.fixed(base.plus(Duration.ofMinutes(6)), ZoneId.of("UTC"));
CacheWithTtl cacheLater = new CacheWithTtl(later, Duration.ofMinutes(5));
// Carry the same data forward for the example
cacheLater.put("session-123", "active");
Optional second = cacheLater.get("session-123");
System.out.println(second.orElse("missing"));
// Expected: missing
}
}
In a real test, you’d avoid re-creating the cache and instead inject a mutable clock (more on that soon), but this shows the principle: with fixed time you can make expiration behavior perfectly repeatable.
A more realistic test: using a controllable clock
Clock.fixed() is immutable, which is great for stability but not great when you need to simulate time passing within one test. A pattern I like is to create a small controllable clock that wraps a Clock and lets me update the instant. I use it only in tests.
import java.time.*;
import java.util.concurrent.atomic.AtomicReference;
public class MutableClock extends Clock {
private final AtomicReference now;
private final ZoneId zone;
public MutableClock(Instant initial, ZoneId zone) {
this.now = new AtomicReference(initial);
this.zone = zone;
}
public void setInstant(Instant instant) {
now.set(instant);
}
@Override
public ZoneId getZone() {
return zone;
}
@Override
public Clock withZone(ZoneId zone) {
return new MutableClock(now.get(), zone);
}
@Override
public Instant instant() {
return now.get();
}
}
Test usage:
import java.time.*;
public class CacheWithMutableClockTest {
public static void main(String[] args) {
MutableClock clock = new MutableClock(Instant.parse("2026-01-01T10:00:00Z"), ZoneId.of("UTC"));
CacheWithTtl cache = new CacheWithTtl(clock, Duration.ofMinutes(5));
cache.put("session-123", "active");
System.out.println(cache.get("session-123").orElse("missing"));
// active
clock.setInstant(Instant.parse("2026-01-01T10:06:00Z"));
System.out.println(cache.get("session-123").orElse("missing"));
// missing
}
}
This is still consistent with the Clock abstraction, but it gives me a single object that can “move” without needing time travel logic inside the service.
Fixed clock in multi-time-zone applications
If your application serves users across multiple regions, you’ll often store timestamps in UTC but display them in user zones. This is where a fixed clock is incredibly useful because you can simulate “now” in a standard instant, and then convert it to different zones to validate formatting, localization, and day boundaries.
Example: show what “now” looks like in Tokyo vs. Los Angeles.
import java.time.*;
public class MultiZoneDemo {
public static void main(String[] args) {
Instant instant = Instant.parse("2026-07-01T12:00:00Z");
Clock fixedUtc = Clock.fixed(instant, ZoneId.of("UTC"));
ZonedDateTime tokyo = ZonedDateTime.now(fixedUtc.withZone(ZoneId.of("Asia/Tokyo")));
ZonedDateTime la = ZonedDateTime.now(fixedUtc.withZone(ZoneId.of("America/Los_Angeles")));
System.out.println("Tokyo: " + tokyo);
System.out.println("LA: " + la);
}
}
By freezing the instant, you can ensure your formatting code isn’t hiding bugs in time-zone conversion logic.
How Clock.fixed() behaves with withZone
One subtle detail: calling withZone on a fixed clock doesn’t change the underlying instant. It only changes how that instant is interpreted when you create zone-dependent types like ZonedDateTime or LocalDate.
That means if you do:
Clock fixed = Clock.fixed(Instant.parse("2026-02-01T00:00:00Z"), ZoneId.of("UTC"));
Clock inParis = fixed.withZone(ZoneId.of("Europe/Paris"));
Both clocks represent the same instant, but the local date/time you see will differ based on the zone. This is exactly what you want when testing formatting and date boundaries.
Common pitfalls with fixed clocks (and how I avoid them)
I already mentioned a few mistakes, but here are more patterns I see when teams adopt Clock.fixed() for the first time.
1) Passing the clock only partway through the stack
If your service uses a clock but a deeper dependency calls Instant.now() directly, you’ve reintroduced a time leak. My fix: I treat time like any other dependency and make sure it flows all the way down.
2) Using LocalDate.now() without a clock
This is an easy mistake:
LocalDate date = LocalDate.now();
That’s a hidden system clock. If you’re using a fixed clock, you want:
LocalDate date = LocalDate.now(clock);
3) Conflating “fixed” with “UTC”
A fixed clock is not the same as UTC. You can freeze any instant in any zone. I always choose the zone based on the business rule, then lock the instant.
4) Forgetting to replace Clock.fixed() in benchmarks
A fixed clock can mask the cost of time-based code because it avoids system calls. If you run performance tests with fixed time, you might underestimate real-world cost. If you’re micro-benchmarking time APIs, always compare system clocks as well.
Alternative approaches to time control
Clock.fixed() is great, but it’s not the only tool. Here are alternatives I’ve used and how they compare.
1) Manual time injection (passing Instant directly)
You can pass Instant or LocalDateTime into methods instead of a clock. That’s useful for pure functions, but it doesn’t scale well to larger services because the signature changes propagate everywhere.
2) Mocking Instant.now() with frameworks
You can use PowerMock or other tools to intercept static calls. I avoid this because it couples tests to implementation details and makes refactoring risky. The Clock abstraction is cleaner and more explicit.
3) Custom Clock implementations
If you need time to move in controlled ways, a custom clock (like the MutableClock example) gives you more power. For most teams, I suggest sticking to fixed and system clocks, then adding a mutable clock only if you really need it.
Testing strategies that pair well with fixed clocks
I’ve found a few testing patterns that become much easier when you’re using Clock.fixed():
1) Boundary testing with table-driven cases
Create a set of “interesting instants” and run the same test logic against each. This pattern is powerful for billing rules and date range filters.
Instant[] cases = new Instant[] {
Instant.parse("2026-02-28T23:59:59Z"),
Instant.parse("2026-03-01T00:00:00Z"),
Instant.parse("2024-02-29T12:00:00Z")
};
for (Instant base : cases) {
Clock fixed = Clock.fixed(base, ZoneId.of("UTC"));
// run the same assertions
}
2) Snapshot tests for date formatting
If you generate human-readable timestamps, a fixed clock lets you snapshot output and keep it stable. This is especially useful in UI or report generation tests.
3) Long-running workflows
If you simulate workflows that span days or months, use a mutable clock to jump time forward without waiting for real time to pass. That keeps tests fast and reliable.
Fixed clocks in scheduled tasks and retry logic
Scheduled jobs and retries often depend on “current time” to compute next run or backoff windows. Here’s a simplified retry policy that’s easy to test with a fixed clock.
import java.time.*;
public class RetryPolicy {
private final Clock clock;
private final Duration baseDelay;
public RetryPolicy(Clock clock, Duration baseDelay) {
this.clock = clock;
this.baseDelay = baseDelay;
}
public Instant nextAttempt(int attemptNumber) {
// Exponential backoff: baseDelay * 2^(attempt-1)
long multiplier = 1L << (attemptNumber - 1);
return Instant.now(clock).plus(baseDelay.multipliedBy(multiplier));
}
}
Test:
import java.time.*;
public class RetryPolicyTest {
public static void main(String[] args) {
Instant base = Instant.parse("2026-01-15T00:00:00Z");
Clock fixed = Clock.fixed(base, ZoneId.of("UTC"));
RetryPolicy policy = new RetryPolicy(fixed, Duration.ofSeconds(10));
System.out.println(policy.nextAttempt(1)); // +10s
System.out.println(policy.nextAttempt(2)); // +20s
System.out.println(policy.nextAttempt(3)); // +40s
}
}
When your retry logic is time-dependent, a fixed clock gives you exact and repeatable expectations.
Logging and auditing: make time explicit
Logs and audit trails often rely on the system time, but your application logic should still be deterministic when possible. A pattern I like is to inject a clock into the domain layer, but use a separate system timestamp for logging. This keeps business behavior stable while still giving accurate operational data.
Example: a service that attaches a domain timestamp and a log timestamp separately.
import java.time.*;
public class AuditEvent {
private final Instant eventTime;
private final String message;
public AuditEvent(Instant eventTime, String message) {
this.eventTime = eventTime;
this.message = message;
}
public Instant getEventTime() { return eventTime; }
public String getMessage() { return message; }
}
public class AuditService {
private final Clock clock;
public AuditService(Clock clock) {
this.clock = clock;
}
public AuditEvent record(String message) {
// Domain time is controlled by the clock
return new AuditEvent(Instant.now(clock), message);
}
}
This makes it easy to test audit behavior without sacrificing real-time logging at the infrastructure level.
Comparing fixed clock to offset and tick clocks
Clock.fixed() is one of three specialized clock behaviors. Knowing how it compares to offset and tick helps you choose the right tool.
What it does
—
Clock.fixed Freezes time at one instant
Clock.offset Shifts a base clock by a duration
Clock.tick Rounds time to a given precision
A pattern I use sometimes: start with a fixed clock, then apply a tick to ensure my code doesn’t rely on sub-second precision.
Practical scenario: “show items created today”
This is a classic bug generator because it depends on local dates and time zones. Here’s an example that uses a clock to make it testable.
import java.time.*;
import java.util.*;
public class ItemService {
private final Clock clock;
public ItemService(Clock clock) {
this.clock = clock;
}
public List createdToday(List items) {
LocalDate today = LocalDate.now(clock);
List result = new ArrayList();
for (Item item : items) {
LocalDate createdDate = item.getCreatedAt().atZone(clock.getZone()).toLocalDate();
if (createdDate.equals(today)) {
result.add(item);
}
}
return result;
}
public static class Item {
private final Instant createdAt;
public Item(Instant createdAt) {
this.createdAt = createdAt;
}
public Instant getCreatedAt() {
return createdAt;
}
}
}
Test with a fixed clock:
import java.time.*;
import java.util.*;
public class ItemServiceTest {
public static void main(String[] args) {
Instant base = Instant.parse("2026-04-10T08:00:00Z");
ZoneId zone = ZoneId.of("America/New_York");
Clock fixed = Clock.fixed(base, zone);
ItemService service = new ItemService(fixed);
List items = Arrays.asList(
new ItemService.Item(Instant.parse("2026-04-10T02:00:00Z")),
new ItemService.Item(Instant.parse("2026-04-09T23:00:00Z"))
);
System.out.println(service.createdToday(items).size());
// Expect 1 for New York date boundary
}
}
Because “today” depends on zone, freezing both the instant and the zone makes the test reliable and precise.
How I document clocks in codebases
When time is a dependency, I add a small note in the constructor or configuration that makes intent clear. I’ve found that a tiny bit of documentation prevents misuse later.
For example:
public class BillingService {
private final Clock clock;
// clock: injected for testability; system clock in production
public BillingService(Clock clock) {
this.clock = clock;
}
}
This isn’t about verbosity. It’s a gentle reminder to future you and other developers that the clock is an intentional dependency, not just an incidental parameter.
Practical checklist: adopting Clock.fixed() safely
When a team adopts fixed clocks, I recommend this checklist:
1) Audit all uses of Instant.now(), LocalDate.now(), and LocalDateTime.now(). Identify where time should be injected.
2) Introduce Clock into those components via constructors.
3) Provide a default Clock.systemUTC() (or system zone) in production wiring.
4) Use Clock.fixed() in unit tests and pick explicit instants.
5) Add boundary tests for DST and midnight transitions.
6) Add a small note or comment where the clock is injected to prevent accidental removal.
This usually takes a day or two for a medium codebase, and the payoff is massive in test stability.
Questions I get asked about Clock.fixed()
Here are a few quick answers to common questions from teammates.
“Can I use Clock.fixed() in integration tests?”
Yes, but it depends. If the system under test also uses real clocks internally, you’ll get inconsistent results. For full integration tests, I try to control time at the top-most boundary of the app so that all components share the same clock.
“What about long-running tests?”
If your tests need time to advance, I use a mutable clock, not a fixed one. I still start with a fixed instant to make the initial state predictable.
“Is Clock.fixed() thread-safe?”
Yes. The returned clock is immutable and thread-safe by design. You can reuse it across threads without worry.
“Should I use UTC or local zone?”
Pick the zone that matches your business logic. UTC is great for storage and cross-service consistency. Local zones are correct for user-facing date rules. The key is to be explicit.
Summary: when Clock.fixed() saves you (and when it doesn’t)
Clock.fixed() is a simple tool that eliminates an entire class of flaky tests and time-based bugs. It gives you a stable, deterministic sense of “now,” which is exactly what you want in unit tests and repeatable calculations. It doesn’t replace real-time clocks, and it shouldn’t be used for scheduling, metrics, or actual timeouts in production.
The mental model I carry is simple: if the code should see time move, use a system clock. If the code should see time stand still, use a fixed clock.
Once you start injecting clocks consistently, you’ll find that date/time logic becomes easier to test, easier to reason about, and less likely to surprise you at 2 a.m. when a DST transition or a midnight boundary hits your production system.
If you want one takeaway from this guide, make it this: don’t let “now” leak into your logic unchecked. Freeze it when you need stability, and use Clock.fixed() as your reliable snapshot of time.
