Worked example: statute of limitations in Canada

6 min read

Published April 8, 2026 • By DocketMath Team

Example inputs

Run this scenario in DocketMath using the Statute Of Limitations calculator.

Below is a worked example of how DocketMath’s statute-of-limitations calculator can model a typical Canadian limitations timeline. This is a calculation walkthrough, not legal advice. In Canada, limitation outcomes depend heavily on the specific cause of action, the province/territory, and the facts (especially dates and when the claimant knew or reasonably ought to have known material facts).

Scenario (used for the example)

A contractor in Ontario performs work for a client. The contract work has alleged defects, and the client claims the contractor’s workmanship caused losses.

To keep the example practical, we’ll use a common structure: a limitation period measured from a trigger date, and DocketMath computes the latest date to start a claim.

Inputs you’d enter (example values)

Assume the following facts for this example:

  • Jurisdiction: Canada (CA)
  • Province/territory: Ontario
  • Claim type: Contract-related civil claim (modeled as a general “civil claim”)
  • Limitation period (years): 2 years
  • Trigger basis: “discover/ought-to-have-discovered” (modeled in this example)
  • Discovery date (YYYY-MM-DD): 2024-03-15
  • Today’s date for the run (YYYY-MM-DD): 2026-04-08

Note: Many Canadian limitations analyses use a “knowledge” concept (when the claimant knew or reasonably ought to have known the material facts). This example uses the discovery trigger because it’s a frequent starting point for civil limitations calculations.

Why these inputs matter

DocketMath’s output is extremely sensitive to:

  • Discovery date (moves the start of the limitation period, which shifts the end date)
  • Limitation period length (controls how far forward the “latest start date” is)
  • Claim category/trigger selection (a different category/trigger can produce a different limitation period or different clock start)

If any of those assumptions don’t match your real-world facts, the computed result may not be directionally correct for your situation.

If you want to try this example in the tool, use: /tools/statute-of-limitations

Example run

Now we’ll compute the latest date to commence a claim based on the inputs above.

Run the Statute Of Limitations calculator using the example inputs above. Review the breakdown for intermediate steps (segments, adjustments, or rate changes) so you can see how each input moves the output. Save the result for reference and compare it to your actual scenario.

Step-by-step (what the tool is doing conceptually)

  1. Start date / trigger:

    • Trigger (discovery) date = 2024-03-15
  2. Add limitation period:

    • Limitation period = 2 years
  3. Compute “latest claim start date”:

    • Latest date = trigger date + 2 years
    • 2024-03-15 + 2 years = 2026-03-15

Result for this worked example

With these DocketMath inputs (CA/Ontario, 2-year limitation, discovery trigger on 2024-03-15):

  • Latest date to start the claim: 2026-03-15
  • Today’s date used for the run: 2026-04-08

Status vs. latest date (simple comparison):

  • Today (2026-04-08) is after 2026-03-15

So, under this modeled scenario:

  • the claim is outside the 2-year window.

Practical timeline table

ItemDate
Discovery (trigger)2024-03-15
Limitation period2 years
Latest date to start claim2026-03-15
Run “today” date2026-04-08
Practical result vs. latest datePast due by 24 days

Practical sanity checks (before you rely on the output)

Before accepting a computed date, quickly verify the “mechanics”:

  • Are you adding calendar years in the way you expect (March 15 → March 15)?
  • Is the trigger properly entered as the date you learned (or reasonably should have learned) the relevant facts under the selected trigger basis?
  • Is the claim type/category aligned with the limitation period you selected in the tool?

Even small date differences (weeks or days) can shift whether the claim is “in time” vs. “late,” especially if the facts are near a boundary.

Sensitivity check

This section shows how the result changes when you tweak one input at a time. This is one of the fastest ways to understand what drives the outcome in a limitations calculation.

To test sensitivity, change one high-impact input (like the rate, start date, or cap) and rerun the calculation. Compare the outputs side by side so you can see how small input shifts affect the result.

Sensitivity 1: Discovery date moves by 30 days

Keep everything the same, but change discovery:

  • Original discovery: 2024-03-15
  • New discovery (later): 2024-04-14 (≈ +30 days)

Recomputed latest date:

  • 2024-04-14 + 2 years = 2026-04-14

Impact compared to the same run “today” date (2026-04-08):

  • 2026-04-08 is before 2026-04-14
  • The claim would be within the window under this modeled scenario
Discovery dateLatest date (2 years later)Status vs. 2026-04-08
2024-03-152026-03-15Past due
2024-04-142026-04-14Not past due

Sensitivity 2: Limitation period changes from 2 years to 6 years

Now change only the limitation period:

  • Trigger date unchanged: 2024-03-15
  • Limitation period: 6 years

Recomputed latest date:

  • 2024-03-15 + 6 years = 2030-03-15

Impact:

  • Today (2026-04-08) is well before 2030-03-15
Limitation periodLatest dateStatus vs. 2026-04-08
2 years2026-03-15Past due
6 years2030-03-15Within window

Sensitivity 3: Comparison date changes

Sometimes the computed “latest start date” stays the same, but your assessment date changes (e.g., when you review the timeline internally vs. when you actually filed).

Assume the latest date is still:

  • Latest date = 2026-03-15

Compare against different dates:

  • Comparison A: 2026-03-10 → within window
  • Comparison B: 2026-03-16 → past due
Comparison dateRelation to latest dateResult
2026-03-105 days beforeWithin window
2026-03-161 day afterPast due

Warning: Being “just inside” or “just outside” can hinge on the selected trigger and the exact dates you input. If your timeline is near a boundary, be especially careful about documenting the factual basis for the trigger date and keeping the same date logic across your notes and filings.

Quick checklist (what to verify when inputs are uncertain)

Use this checklist while running your own scenario:

Related reading