“Within 21 days after being served” is not a date and should not be stored as one. It is an obligation with a trigger, a period and a counting rule, and the trigger is usually recorded in a different document from the one you are reading.
Two different fields wearing one name
Court documents contain dates of two entirely different kinds, and conflating them is the source of most of the trouble.
- Absolute dates that somebody has already fixed: a hearing set for a particular day and time, a trial date in a scheduling order, a status conference. These are stated on the page and need transcription, not computation.
- Relative deadlines expressed as a period from an event: “within 21 days after service of the summons and complaint”, “no later than 14 days before the hearing”, “within 28 days after the entry of judgment”. These are rules. Resolving one to a calendar date requires a trigger date, a counting convention and a holiday calendar, none of which are on the page.
- Dates that are neither and get swept up anyway: the date the document was signed, the date of the certificate of service, dates recited in the factual background, and the filing date in the electronic header stamp.
A schema with a single deadline field forces all three into one shape and the pipeline into guessing. Model them separately, and give every extracted date a type and the sentence it came from.
Absolute dates: time, place and department
A hearing date without its time is an incomplete record, and a hearing date without its location is one somebody misses. Notices of hearing state all three together:
PLEASE TAKE NOTICE that the above-entitled motion will be heard on
Tuesday, April 15, 2025, at 9:30 a.m., or as soon thereafter as the
matter may be heard, in Courtroom 5B of the above-entitled Court,
before the Honourable Jamie K. Lee.
Extract the date, the time, the courtroom or department, and the judge as separate fields, plus the qualifying language. “Or as soon thereafter as counsel may be heard” means the stated time is a calendar call, not an appointment; a downstream system that treats it as a hard appointment will be wrong in a harmless direction, but a system that shows the practitioner the qualifier is more useful.
Store the time zone as the court’s local zone, identified from the court rather than from your server. This is a genuine source of off-by-one-day errors: a hearing at 9:00 a.m. in a Pacific court, normalised to UTC and rendered in a European office, is a meeting the previous evening in a calendar view and a date that no longer matches the document.
A deadline is a triple, not a date
The right output for a relative deadline preserves its three parts and resolves them later, if at all:
{
"kind": "relative_deadline",
"obligation": "serve a responsive pleading",
"period": { "count": 21, "unit": "days" },
"relation": "after",
"trigger_event": "service of the summons and complaint",
"trigger_date": null,
"rule_cited": "Fed. R. Civ. P. 12(a)(1)(A)(i)",
"rule_set": "frcp",
"source_text": "within 21 days after being served with the summons and complaint",
"resolved_date": null,
"resolution_basis": null
}
The trigger_date is null because the document rarely contains it. A complaint does not know when it was served; the proof of service — a separate document, filed later, sometimes weeks later — records that. That is a required field legitimately absent from the source rather than a failed read, and the two want different handling. So the extraction from this document is complete and correct while still not producing a date, and the resolution happens in a different step that joins the obligation to whatever document supplies the trigger.
This is also why the arithmetic should not live inside the model call. A model asked to produce a date will produce one, and the date it produces has no audit trail: you cannot tell afterwards which trigger it assumed, which counting rule it applied or whether it noticed a holiday. Extract the components with the model, compute the date in ordinary code, and record in resolution_basis which rule and which trigger the computation used. The general argument for splitting reading from reasoning is in extract then reason.
The counting rules are not obvious
Even with a trigger date in hand, the arithmetic is not “add 21”. In federal civil practice the counting conventions live in Rule 6 of the Federal Rules of Civil Procedure, published in full by the Legal Information Institute at Cornell, and the parts that matter to a computation are these. For a period stated in days you exclude the day of the triggering event and count every day after it, including Saturdays, Sundays and legal holidays. If the last day falls on a Saturday, a Sunday or a legal holiday, the period runs to the end of the next day that is none of those. Periods stated in hours are counted differently again, and a period measured backwards from an event — “14 days before the hearing” — has its own end-of-period rule that runs in the opposite direction.
Rule 6(d) adds a further wrinkle: where service was made by certain means, three days are added after the period would otherwise expire. Which means qualify has itself been narrowed by amendment, which is exactly why the rule set and its date belong in the stored record rather than being baked into a function.
The holiday calendar is not a fixed list either. Rule 6 defines legal holidays to include federal holidays and, for periods measured in a particular court, days declared holidays by the state where that court sits. Add court closure orders — weather, emergencies — which are published by the individual court and not by anyone else. So a correct computation depends on a per-court calendar, and a pipeline that ships one national holiday list will be quietly wrong in some districts on some days.
Rule numbering and the counting conventions have both been amended within recent memory, the federal time-computation package of 2009 being the largest such change. Any implementation should cite the rule version it implements and be revisited against the current text. This page describes how to structure the extraction; it is not legal advice and a computed date is a draft for the person who is responsible for the docket.
Ambiguous dates and the trigger problem
Two transcription hazards are worth naming because they are silent.
The first is numeric date order. 03/04/2025 is 3 April in most of the world and 4 March in the United States, and both readings are valid dates, so nothing downstream errors. Court documents mostly spell the month out in the body — “March 12, 2025” — but the electronic filing header stamp uses numerals, exhibits use whatever their author used, and correspondence attached as an exhibit may well be from a jurisdiction with the other convention. Record the literal string alongside the parsed date and the convention you assumed; where the day is 13 or higher the order is determined by the value and where it is not, the assumption is doing real work.
The second is the wrong trigger. Documents often contain several dates that could plausibly start a clock: the date the document is dated, the date in the certificate of service, the filing date in the header stamp, and the date an order was entered. These differ, sometimes by weeks, and the rule specifies which one applies — service, entry or filing — in language that a general-purpose extraction will flatten. Keep the trigger as the described event, not as a date the model picked, and let the joining step decide which recorded date satisfies it. Where no candidate exists, an unresolved deadline surfaced to a human is the correct output, and the review path for that is the same threshold-based routing used for any low-confidence field.
Top comments (0)