When I built a small deadline calculator, the hard part was not adding N days. The hard part was avoiding the quiet assumptions that make date tools wrong.
Here is the checklist I now use before trusting a court-day or business-day calculation:
- Decide whether the start date counts. Many workflows start counting from the next day, not the event day.
- Separate calendar days from court/business days. A UI should make that choice explicit.
- Treat weekends as data, not decoration. They change the result, so they need tests.
- Keep holiday rules visible. If the jurisdiction or court has a special closure, the calculator should not pretend to know it unless that rule is actually encoded.
- Show the skipped dates. A final date without the path is hard to audit.
- Keep a disclaimer near the result. A calculator can help with arithmetic, but it cannot replace the controlling local rule or court order.
A tiny test fixture I like is this shape:
const result = addCourtDays({
startDate: '2026-06-16',
daysToAdd: 10,
holidays: ['2026-06-19'],
countFromNextDay: true
})
console.assert(result.dueDate === '2026-07-01')
I keep a public reference implementation here: Court Days Calculator. I use it as a quick arithmetic sanity check, not as legal advice. The useful part is that it shows the counted and skipped days so the result can be reviewed instead of blindly copied.
The broader lesson applies to any date-heavy product: make the rule choices visible, test the exceptions, and avoid hiding uncertainty behind a single confident-looking date.
SOCIAL SHARE CARD GENERATOR