How to run deadlines in DocketMath for New York

6 min read

Published April 8, 2026 • By DocketMath Team

Step-by-step

This guide walks you through running deadline calculations in DocketMath for New York (US-NY) using the deadline calculator. It assumes you’re using DocketMath for workflow timing (for example, tracking “no later than” dates) rather than relying on it as legal advice.

Before you start, confirm the deadline logic you want DocketMath to follow:

  • New York general period (default): 5 years
  • General statute cited: N.Y. Crim. Proc. Law § 30.10(2)(c)
    Source: https://www.nysenate.gov/legislation/laws/CPL/30.10
  • Important limitation for this guide: a claim-type-specific sub-rule was not found here, so the 5-year period is treated as the general/default period.

Gentle note: This is a practical workflow walkthrough. If your matter may involve a different rule than the general/default period, verify the applicable rule before finalizing dates.

1) Open the deadline calculator

  1. If DocketMath prompts you to choose a jurisdiction, select US-NY (New York).

2) Enter the trigger date (the “start” of the clock)

DocketMath needs a start date—commonly the date the relevant event occurred (for example, when the timeline begins in your workflow).

Use whichever date matches what you’re tracking internally, such as:

  • filing date
  • incident date
  • service date
  • notice date (depending on what you’re modeling)

How outputs change:
Changing the trigger date shifts every computed deadline proportionally, since the period is added from that start.

3) Confirm the period length used (default = 5 years)

In this New York setup, the calculator will run with the general/default period:

  • 5 years, tied to **N.Y. Crim. Proc. Law § 30.10(2)(c)

Note: This guide uses the general/default 5-year period because no claim-type-specific sub-rule was found in the brief. If your situation falls under a different rule, adjust your inputs accordingly or validate the rule before finalizing dates.

4) Choose the calculation mode (calendar math vs. “last day”)

Most deadline tools include a choice such as:

  • “Add years and output the resulting date”
  • “Compute last permissible day”
  • “Adjust for weekends/holidays”

Pick the mode that matches how your workflow documents deadlines:

  • If your process says “due by end of day” on the computed date, choose the “last permissible day” style.
  • If your workflow is designed around a submission window, choose the mode that best reflects how you interpret “by” deadlines.

How outputs change:
Even with the same 5-year period, the “due” date can differ depending on whether DocketMath applies weekend/holiday adjustments.

5) Review DocketMath’s output set

After you run the calculation, DocketMath typically provides values such as:

  • the computed deadline date
  • time remaining (if it calculates from “today”)
  • a timeline snapshot you can save for your record

Use the computed deadline date for your docket/work order. If you create a task, paste the deadline date into the task title or due field.

6) Create an internal checklist entry

For each run, create a lightweight audit trail so you can reproduce the calculation later.

Use this checklist style:

7) Re-run when any input changes

Common reasons to re-run:

  • the trigger date is corrected
  • you change how your team interprets “by” deadlines
  • you switch weekend/holiday adjustment mode
  • you update assumptions after reviewing additional facts

How outputs change:
Even a 1-day change to the trigger date will typically shift the resulting deadline by about 1 day, unless weekend/holiday adjustment logic changes the outcome.

Common pitfalls

Deadlines are easy to mis-run when assumptions and inputs don’t match. These New York workflow errors are common when using the tool.

  1. Using a non-default rule accidentally

    • If your matter doesn’t actually fall under the general/default rule, a blanket 5-year run may be wrong.
    • This guide intentionally uses the general/default period based on N.Y. Crim. Proc. Law § 30.10(2)(c), because no claim-type-specific sub-rule was found for this brief.
  2. Confusing “trigger date” with “processing date”

    • Start with the date the clock truly begins in your workflow.
    • If your team starts the clock at the date the issue was noticed (instead of the event date), deadlines can drift.
  3. End-of-day vs. same-day interpretation

    • Teams often interpret “by [date]” as “end of that calendar day.”
    • If DocketMath’s selected mode doesn’t mirror your interpretation, urgency and cutoffs may be off.
  4. Weekend/holiday adjustment not matching how you file

    • If your office treats weekends/holidays using a particular workflow rule (for example, “next business day”), ensure DocketMath’s adjustment mode matches that standard.
  5. Not recording which period and options were used

    • If you later need to explain the computed date, you’ll want a record showing:
      • Jurisdiction: US-NY
      • Period: 5 years
      • Source: **N.Y. Crim. Proc. Law § 30.10(2)(c)

Pitfall: Running the calculation twice with different weekend/holiday settings can produce two different “due” dates. Pick one workflow standard and use it consistently.

Try it

Follow this quick “safe test” approach to validate your DocketMath run before relying on it for real work.

Open the Deadline calculator and follow the steps above: Run the calculator.

If an assumption is uncertain, document it alongside the calculation so the result can be re-run later.

1) Do a single run with a known start date

  • Set US-NY
  • Enter a start date you can verify easily (for example, a date already recorded in your case notes)
  • Run using the general/default 5-year period under **N.Y. Crim. Proc. Law § 30.10(2)(c)

2) Compare the result to a quick sanity check

Without changing any options, check:

  • Does the computed deadline land exactly 5 calendar years later (or very close if weekend/holiday adjustment applies)?
  • If DocketMath shows time remaining, does it fall within the expected range?

3) Re-run after changing only one input

Change one thing at a time:

  • move the start date by 1 day, or
  • switch weekend/holiday adjustment mode, or
  • switch “by deadline vs. as-is” behavior

Then confirm:

  • the deadline shifts in the direction you expect
  • you understand why (for example, an adjustment pushed the date forward)

4) Save the correct version

When you get a result that matches your intended workflow rule:

  • keep those settings for subsequent tasks
  • update only the trigger date if facts change

Related reading