Why deadlines results differ in New Hampshire

6 min read

Published April 8, 2026 • By DocketMath Team

This article is for informational purposes only and does not constitute legal advice. Laws change frequently — verify all citations with current official sources.

The top 5 reasons results differ

Run this scenario in DocketMath using the Deadline calculator.

If you’re using DocketMath to compute a deadline in New Hampshire (US-NH) and you see a mismatch, the cause is usually one of five “deadline inputs” that don’t align between your sources.

In New Hampshire, the general civil statute of limitations (SOL) period is 3 years under RSA 508:4. This is the default/general rule used for many civil claims. No claim-type-specific sub-rule was found for this diagnostic, so for the purposes of this “why results differ” check, treat 3 years as the baseline unless you already know a different, specific limitations rule applies.

Below are the most common reasons deadline results diverge.

**Different starting dates (“accrual” vs. filing date)
- Many calculators accidentally use the filing date as the start instead of the date the clock began running (often called the accrual date).
- In DocketMath, your computed deadline can change immediately if the start date changes by even a few days.
Time-of-day / “end of day” assumptions
- Some systems treat a deadline as expiring at the end of the day, while others treat it as expiring at a specific time or use different cutoffs.
- Even if both show the same calendar date, the internal cutoff can differ, which can matter for edge cases.
Calendar-day vs. business-day roll logic
- Some tools roll a deadline that lands on a weekend/holiday to the next business day; others don’t.
- That difference often shows up when the computed date is near a holiday or weekend, producing a one-day (or more) shift.
Mixing “SOL deadline” with other court deadlines
- A statute of limitations deadline is about whether a claim is timely filed.
- Other “deadlines” (service, hearings, motion schedules, procedural deadlines) follow different rules and shouldn’t be compared as if they’re the same thing.
**Bad or misread dates (OCR, formatting, or month/day swaps)
- A common root cause is a transcription error like:
  
  OCR misreads,
  
  spreadsheet conversions,
  
  or confusing MM/DD vs DD/MM formats.
- A single swapped day/month value can make the deadline look clearly “wrong,” even if the calculation logic is fine.

Practical heuristic: If your two results differ by a pattern (e.g., exactly by whole months/years), suspect the start date or baseline period first. If the results differ by just a day or two, suspect roll logic (weekends/holidays) or time-of-day/end-of-day assumptions.

How to isolate the variable

Use this short checklist to pinpoint what changed. The goal is to confirm that both computations use the same inputs and the same rule set (especially the same start-date concept and the same roll/calendar logic).

Freeze the jurisdiction and tool settings so both runs use the same rule set.
Compare one input at a time (dates, rates, amounts) and re-run after each change.
Review the breakdown to see which segment or assumption drives the difference.

1) Confirm the baseline period you’re applying

Baseline for this diagnostic: General SOL Period = 3 years
Authority: RSA 508:4
Important: Because no claim-type-specific sub-rule was found for this diagnostic, if one of your results is based on anything other than the general 3-year baseline, the outputs can legitimately diverge.

2) Align the “start date” used by each workflow

Make a side-by-side table and compare the exact date each system treats as the “clock start”:

Input	Result A	Result B
Start date (accrual / clock start)
End date (computed deadline)
Period length	3 years?

If the start date differs, the mismatch is often explained immediately.

3) Check calendar roll rules (weekends/holidays)

Look for any rule such as:

“If the deadline falls on a weekend/holiday, move to next business day,” or
“Expires on the last calendar day of the period.”

If one tool uses business-day adjustments and the other uses straight calendar days, the final date can shift.

4) Verify you’re comparing the same type of deadline

Ask: what does each result represent?

Statute of limitations / timeliness for filing (what you want for SOL comparisons)
versus service deadlines
versus procedural/court scheduling deadlines

If one output is a court-procedure deadline, it won’t line up cleanly with a statute-of-limitations deadline.

5) Re-run DocketMath with controlled changes

To isolate the cause, change only one variable at a time:

Keep everything the same.
Change the start date by 1 day.
Recompute and compare how much the output moves.

If the output difference matches the input change (or matches a roll rule boundary), you’ve found the likely driver.

For a quick re-check using DocketMath, use:

/tools/deadline (the Deadline tool)

Next steps

Use the same baseline rule
- For this diagnostic, stick to RSA 508:4 = 3 years (general/default SOL period).
- If you already know your situation involves a special rule for a specific claim type, you’ll need to swap the baseline accordingly before comparing results.
Write down the start-date rationale
- Record what event supports the start date (e.g., “clock started on [event date]”).
- This prevents accidental drift when someone else repeats the calculation.
Recompute in DocketMath with aligned inputs
- Confirm:
  
  start date,
  
  period length (3 years, for the general/default baseline),
  
  and any roll/calendar assumptions that your other source uses.
Compare the “why” behind the mismatch
- If the start date differs → fix the input.
- If roll logic differs → match the same calendar/business-day logic.
- If the source used a different deadline type → use the SOL deadline only for SOL comparisons.

Gentle note: This diagnostic helps explain why two deadline calculations differ. It doesn’t by itself determine what deadline applies to a specific claim beyond the general/default SOL baseline described above.