If you’ve ever tried to calculate a legal filing deadline, you know it’s not as simple as “incident date + X years.” In many cases, multiple rules apply — each with its own logic, timelines, and exceptions.

That’s where the fun begins.

Imagine a single case producing three possible deadlines:

• Occurrence rule: X years from the date of the incident.
• Discovery rule: X years from when the harm was (or should have been) discovered.
• Statute of repose: An absolute cutoff date, regardless of discovery or occurrence.

Each of these is designed to serve a purpose, but together, they can create conflicting results. Which one wins?

The Tie-Breaker Problem

In real-world practice, the “winning” deadline depends on jurisdiction and statute language. Sometimes the earliest date controls (“earliest wins” rule). Other times, discovery may extend the timeline unless a repose period cuts it off.

If you hard-code these decisions in every calculator, you’re setting yourself up for chaos. Change the tie-breaking logic once, and suddenly you’re hunting through multiple files, hoping you didn’t miss anything.

Enter the Utility Class

To solve this, I created a calculator utility class that:

1. Applies each rule independently — occurrence, discovery, repose, and others.
2. Normalizes the results into a common format.
3. Determines the effective deadline based on the jurisdiction’s tie-breaking rule.

By isolating this logic:

• The calculators stay lean and readable.
• Tie-breaking behavior is consistent across all practice areas.
• New rules (or rule combinations) can be added without rewriting everything.

Why It Works

• Centralization – One place to change core date-comparison logic.
• Transparency – Easy to explain why a deadline was chosen over another.
• Testability – Unit tests can target the decision-making engine directly.

In short, the utility class became the “referee” — applying the law’s rules in order, then declaring the winner without bias.

The Bigger Picture

This approach isn’t just for statutes of limitations. Any system where multiple time-based rules can apply — contract expirations, compliance deadlines, insurance claims — can benefit from the same pattern.

When rules collide, it’s not enough to calculate dates. You need a consistent, tested, and explainable way to decide which date matters most.

And that’s why my utility class isn’t just a helper. It’s the judge, jury, and timekeeper.

Thanks for reading!

About the Author

Paul A. Jones Jr. is a software engineer and legal tech founder developing tools for professionals in law and other regulated industries. He writes about systems thinking, modern workflows, and SaaS applications at PaulJonesSoftware.com. Follow him on Twitter: @PaulAJonesJr.

You Might Also Enjoy

• “The Six Pillars of Legal Tech” → Explore foundational principles for scalable legal software.
• When Architecture Matures: The Rise of Reuse in Legal Tech → Explore how modular design and reuse principles elevate legal software from tactical tools to strategic infrastructure.
• “Understanding Legal Deadlines” → Learn how to audit and explain filing timelines with confidence.