How to run deadlines in DocketMath for United States (Federal)

6 min read

Published April 8, 2026 • By DocketMath Team

Step-by-step

Run this scenario in DocketMath using the Deadline calculator.

This guide walks you through running deadlines in DocketMath for United States (Federal) matters (US-FED). You’ll learn which inputs to use, what the output means, and how to sanity-check the result against typical Federal time-period concepts.

Quick scope note: DocketMath helps you calculate dates and time periods—it doesn’t replace legal judgment about which rule applies to your specific situation, or how a particular court treats timing in its orders.

1) Open the deadline calculator

  1. Go to /tools/deadline
  2. Select the jurisdiction United States (Federal) (code: US-FED)

2) Choose the “starting point” date

Federal deadlines are often computed from an event date—commonly filing, service, or entry. In DocketMath, you’ll typically supply a Start date (sometimes described as the event date).

Pick a date you can reliably point to in the docket or certificate of service, such as:

  • Date filed (if the deadline runs from filing)
  • Date of service (if the deadline runs from service)
  • Date of entry (if the deadline runs from an order being entered)

Warning: Don’t mix up mailing date vs. service date. In Federal practice, some deadlines run from when service is completed, and the method of service can affect the calculation.

3) Enter the deadline type / duration

The DocketMath deadline calculator is designed for time-period calculations. Look for the control that matches what you need, such as:

  • A fixed number of days
  • Or a rule-based window where you set the period (e.g., “X days”)

If you’re using a “number of days” approach, you’ll typically enter:

  • Days count (e.g., 14, 21, 30)
  • The direction (forward from the Start date)

Also choose the relevant day-count convention if the UI offers it:

  • Calendar days vs. business days

Many Federal rules use calendar days, but some contexts (and some court orders) use different conventions—so match what you’re working from.

4) Apply Federal “rule” adjustments (if available)

Federal deadline counting commonly includes adjustments such as:

  • Excluding the event day when required by the applicable method
  • Rollover (extending a deadline that lands on a non-business day to the next business day)

In DocketMath, this is usually controlled by an option/toggle such as Federal adjustments or roll forward if needed.

For US-FED computations, use the option that corresponds to Federal deadline rules for your scenario. If you’re unsure whether an adjustment should apply, it’s usually best to run the calculator both ways (see “Try it” below) and compare.

5) Review the output: due date and calculation details

After you run the calculator, DocketMath should return both the result and enough detail to verify how it got there, typically including:

  • **Calculated deadline (due date)
  • A breakdown or trace showing start date, count, and any rollover/adjustment behavior

Use the output like a checklist:

Output itemWhat it tells youWhat to do next
Due dateThe final computed deadlineCompare to your court’s scheduling/order language
Roll/adjustment indicatorWhether a non-business-day shift occurredConfirm the shift aligns with your expectation of business-day handling
Count basis (calendar vs business)How the calculator counted the daysEnsure it matches the time period you intended
Calculation traceIntermediate logic/datesKeep it internally so you can explain your inputs later

6) Validate with a quick “reasonableness” check

Before you treat the due date as final, do a fast sanity check:

  • Does the due date land too soon or too far relative to the Start date?
  • Did a rollover happen (e.g., the computed date would have been on a weekend/holiday)?
  • Does the date behavior make sense for the length you entered (for instance, “21 days” usually won’t behave exactly like “3 weeks” if rollover rules are involved)?

This isn’t legal advice—just a practical workflow step to catch common date-entry mistakes.

Common pitfalls

Federal deadlines get tripped up in a predictable set of ways. Here are the most common issues when running deadline calculations in DocketMath for US-FED matters.

  • counting from the wrong triggering event
  • ignoring court-closed days or holiday rules
  • mixing calendar days with court days
  • missing time-of-day cutoffs for filing

Pitfall checklist

Pitfall: “Close enough” can be risky. Entering 14 vs. 21 days doesn’t just shift a date—it can affect whether your filing/response is timely.

A practical example of what to watch

If the due date depends on when service is completed, two common problems are:

  1. You enter the mailing date when the trigger is service completion
  2. You enter a service date/method date, but the calculation also applies a service-related extension automatically

To avoid this, make sure your Start date matches the trigger you intend, and then carefully choose whether to enable Federal adjustments—avoid duplicating the same extension in two places.

Try it

Ready to run your own calculation? Use /tools/deadline and follow this workflow:

  1. Open /tools/deadline
  2. Set jurisdiction to United States (Federal) — US-FED
  3. Pick your Start date (the event you’re counting from)
  4. Enter the deadline period (for example: 14, 21, 30 days)
  5. Enable Federal adjustments (especially rollover behavior) if that option is available for your setup
  6. Click Calculate
  7. Confirm the due date and check whether a rollover happened

If you want to stress-test your configuration, run two versions:

  • Run A: Federal adjustments ON
  • Run B: Federal adjustments OFF

Compare the due dates. If they differ, review whether your scenario should include those adjustments as part of the computation.

For a faster “audit trail,” keep a small inputs log each time you run it:

  • Start date used
  • Deadline period (days)
  • Adjustment setting (on/off)

That way, if you need to explain the due date later, you can point to the exact inputs rather than re-guessing.

Related reading