Worked example: deadlines in New Hampshire

Example inputs

This worked example shows how DocketMath’s deadline calculator might model a civil statute of limitations deadline in New Hampshire using the state’s general/default SOL rule.

Here is a simple illustration for New Hampshire. These values are for demonstration only and should be replaced with your actual inputs.

• Principal or amount: undefined
• Rate or cap: N/A
• Start date: 2025-04-02
• End/as-of date: N/A

Governing rule (general/default)

• RSA 508:4 provides the general 3-year statute of limitations for civil actions in New Hampshire.
• No claim-type-specific sub-rule was found for this example, so this calculation uses the general/default 3-year period (not a special shorter/longer limitation).

Scenario for the example

Assume a plaintiff is basing a civil claim on an event that occurred on a specific date. We’ll compute the latest plausible “file-by” date using the general 3-year SOL.

Use these inputs:

• Event date (trigger): January 15, 2023
• Claim type: Not applying any special claim-category rule in this example (since none was identified here), so the general/default 3-year period applies.
• SOL period: 3 years, from RSA 508:4

Output we’ll compute

• Estimated deadline (latest filing date): calculated by adding 3 years to the trigger date using a same calendar date 3 years later approach (i.e., a straightforward date-add model).

To run the calculator, you can start here: /tools/deadline.

Example run

Below is a plain-English “run” of what DocketMath would do with the inputs above, applying New Hampshire’s general/default 3-year SOL under RSA 508:4.

Run the Deadline 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 1: Confirm the SOL period being used

From the brief:

• General SOL Period = 3 years
• Source: RSA 508:4
• Rule selection: general/default, because no claim-type-specific sub-rule was identified for this example

So the model uses:

• Limit length: 3 years
• Rule selection: general/default only (no special category)

Step 2: Add 3 years to the trigger date

• Trigger date (event date): January 15, 2023
• Add 3 years → January 15, 2026

Step 3: Determine the estimated “file-by” deadline (model output)

Using a straightforward calendar-based SOL model, the deadline becomes:

• Estimated SOL deadline: January 15, 2026

Here’s the same information as a quick table:

What you’d enter in DocketMath (conceptually)

In DocketMath’s guided deadline flow, conceptually you would:

1. Choose the deadline calculator.
2. Select New Hampshire (US-NH).
3. Provide the trigger date (January 15, 2023).
4. Ensure the calculation is using the general/default 3-year period (not a special category).

If you want to repeat this with other dates, use the calculator directly: /tools/deadline.

Sensitivity check

Even when the same general rule applies, the computed deadline can change when the trigger date shifts or when calendar edge cases matter (like leap years). This section tests sensitivity while keeping the governing rule fixed: New Hampshire general SOL = 3 years under RSA 508:4.

Sensitivity A: Event date moves by 10 days

Change only the trigger date and re-run the same “+3 years” model.

• Original trigger: 2023-01-15 → deadline 2026-01-15
• New trigger: 2023-01-25 → deadline 2026-01-25

Result: the deadline shifts by the same amount (+10 days) because we’re applying a simple same-date-year addition.

Sensitivity B: Leap-year boundary (non-leap-day selection)

For a trigger date that is not Feb 29, the same calendar date logic is straightforward.

Example:

• Trigger: 2024-02-28
• • 3 years → 2027-02-28

Sensitivity C: Leap-day trigger (February 29 handling)

Leap day (2024-02-29) can produce different “effective” deadlines depending on how a system maps Feb 29 to a non-leap year.

Common approaches in date calculators include mapping to:

• Feb 28, or
• Mar 1, or
• using an explicit internal convention

Because this post is focused on illustrating the mechanics under RSA 508:4’s general 3-year period, treat leap-day behavior as a modeling detail to verify in DocketMath.

Practical check: Run DocketMath for the same jurisdiction/rule using these trigger dates:

• 2024-02-28
• 2024-02-29
• 2024-03-01

Then compare the computed deadlines to see exactly how the calculator handles Feb 29 in your chosen model.

Sensitivity D: Rule selection (general/default vs special category)

This example intentionally uses general/default only:

• No claim-type-specific sub-rule was found
• So we keep the calculation at 3 years under RSA 508:4

In real cases, another rule could apply if a specific category/exception exists and is identified for that claim type. If DocketMath allows you to choose a special SOL category (or if you learn one applies), then the deadline could change from the 3-year general baseline.

To keep this worked example honest, we:

• did not apply any special claim category
• used RSA 508:4’s general 3-year period

Related reading

• Why deadlines results differ in Canada — Troubleshooting when results differ
• Worked example: deadlines in New York — Worked example with real statute citations
• Emergency deadline checklist for Canada — Emergency checklist and quick-reference inputs