Spreadsheet checks before running statute of limitations in California

What the checker catches

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

Before you run a California statute of limitations (SOL) calculation in a spreadsheet, do a quick “sanity-check” pass. DocketMath’s statute-of-limitations calculator works best when your date fields, logic, and assumptions are consistent with California’s default rule.

California baseline the checker uses

California’s general/default SOL period is 2 years under CCP §335.1 (default baseline only). The checker below uses this general rule; it does not apply claim-type-specific time periods (since a claim-type-specific sub-rule wasn’t identified in the brief).

Use this as a spreadsheet mechanics and baseline-validation step—not as a claim-specific legal conclusion.

A spreadsheet checker should catch problems in four areas

1. Missing or mismatched date inputs

   • Typical date fields you may need:

     • Event/incident date (start/accrual date for your default baseline)
     • Filing date (the date you compare to your calculated deadline)
   • Common failure: one date is stored as text (for example, "2024-01-05"). When that happens, date math can return blanks, zeros, or incorrect comparisons.

2. Wrong “start date” assumption

   • Your spreadsheet often has multiple date candidates (e.g., IncidentDate, AccrualDate, NoticeDate).
   • A sanity-check should enforce that only one date column is used as the SOL start date for the default 2-year rule.
   • Catch scenario: formulas accidentally reference AccrualDate in one place and IncidentDate in another, creating inconsistent deadlines and statuses.

3. Off-by-one and date/datetime truncation errors

   • If you mix date-only values with timestamps (date + time), calculations can drift by a day depending on parsing and timezone handling.
   • A practical checker rule: normalize all relevant inputs to date-only before calculating deadlines and comparing “on or before” vs “after.”

4. Boolean logic slips in pass/fail outputs

   • You want a clear status, such as:

     • Within default SOL
     • **Potentially time-barred (default rule)
   • Common failure: formulas treat blank cells as zeros or convert missing dates into a “pass,” which can make results look deceptively valid.

Quick checklist (mechanical validation)

Use this checklist before relying on any spreadsheet output:

When to run it

Run the checker before you calculate SOL across your dataset, and again after any data preparation or formula changes.

A practical cadence:

1. Right after importing data

   • Examples:

     • CSV import from case management software
     • Copy/paste from another system that may format dates differently

2. After you adjust date formats

   • If you changed date formats (e.g., MM/DD/YYYY to YYYY-MM-DD) or re-parsed columns, rerun the checker immediately.

3. After you edit formulas

   • Formula repairs are where subtle bugs hide:

     • wrong cell reference
     • swapped column names
     • inconsistent use of the start date

4. Before generating final reports/exports

   • Rerun right before you export results so the spreadsheet you send (and the status labels you trust) reflect the corrected logic.

Try the checker

DocketMath’s statute-of-limitations tool is a simple way to confirm your spreadsheet’s mechanics match a known baseline.

Upload the spreadsheet, review the warnings, and then run the calculation once the inputs are clean: Try the checker.

Baseline inputs to test

Start with the default baseline:

• Statute of limitations period: 2 years
• General statute citation: CCP §335.1
• Important note: This is the default general rule only (no claim-type-specific time period is applied in this baseline check).

Step-by-step spreadsheet sanity test

1) Confirm your input columns

Dedicate columns for the two roles your logic needs:

• EventDate (the start date you’re using for the default baseline)
• FileDate (the filing date you compare against the deadline)

Then make sure derived columns (like DaysBetween, DeadlineDate, Status) reference those exact fields—consistently.

2) Normalize date formats

Use one consistent representation:

• Convert EventDate and FileDate to date-only
• Fix parsing warnings before calculating deadlines

3) Compute the default deadline using the 2-year rule

Your spreadsheet should yield one consistent DeadlineDate:

• DeadlineDate should be a real date
• DeadlineDate should change when EventDate changes
• DeadlineDate should not “freeze” due to broken references

Your checker should flag:

• invalid or blank DeadlineDate
• deadlines that don’t update after editing EventDate

4) Produce a deterministic status

For the default baseline, define a clear comparison rule:

• If FileDate is on or before DeadlineDate → Within default SOL
• If FileDate is after DeadlineDate → **Potentially time-barred (default rule)

A sanity-check should ensure statuses aren’t blank and that only one status appears per row (no contradictory logic).

5) Cross-check with DocketMath

Now compare your spreadsheet’s outputs with DocketMath for the same sample rows.

• Use the same EventDate and FileDate
• Compare:

  • the computed deadline date
  • the within/beyond status
  • how your sheet handles date-only inputs

If results differ, troubleshoot in this order:

1. date parsing/formatting
2. start date column selection
3. “on or before” vs “before” comparison logic
4. hidden filters or row-level conditionals

Reference point: DocketMath tool

For the baseline comparison, use DocketMath’s tool here: /tools/statute-of-limitations.

Related reading

• Choosing the right statute of limitations tool for Vermont — How to choose the right calculator
• Statute of limitations in Singapore: how to estimate the deadline — Full how-to guide with jurisdiction-specific rules
• Choosing the right statute of limitations tool for Connecticut — How to choose the right calculator