DEV Community: Xian X

Date-counting bugs I test before shipping a deadline calculator

Xian X — Wed, 17 Jun 2026 17:04:36 +0000

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.

Date math notes for a court deadline calculator

Xian X — Tue, 16 Jun 2026 04:47:07 +0000

Date calculators look simple until the rules around the date become the main product. I have been using a small court-day calculator as a reminder to keep the implementation boring, explicit, and easy to audit.

The most important design decision is to separate ordinary calendar math from jurisdiction-specific legal rules. A tool can help someone count days, compare deadlines, and avoid manual arithmetic mistakes, but it should not pretend to replace local court rules or legal advice. That boundary needs to be visible in both the interface and the page copy.

For the calculator workflow, I keep a few implementation notes close to the code:

Normalize all input dates before doing any counting.
Show the start date and end date in the result, not only the final number.
Make weekend and holiday assumptions explicit.
Keep a plain-language explanation beside the result so users can catch obvious mistakes.
Avoid hidden defaults when a date rule could change the answer.

The small calculator page I am using for these checks is here:

https://courtdayscalc.com/

A useful test case is to compare a short same-week range, a range that crosses a weekend, and a range that crosses a month boundary. Those three cases catch many accidental off-by-one errors before the tool reaches real users.

For any legal-adjacent utility, clarity matters more than cleverness. The safest pattern is to make the arithmetic transparent, expose assumptions, and tell users when they need to verify a rule outside the tool.

Notes from maintaining a small game reference page

Xian X — Tue, 16 Jun 2026 04:42:23 +0000

I have been keeping notes on a small fan reference page and wanted to write down the checks that made it less fragile. The main lesson is that a reference page should not try to look bigger than the information it can verify. A short page with clear scope is more useful than a large page padded with guesses.

For game notes, I now separate three things before publishing: confirmed mechanics, change-prone observations, and open questions. Confirmed items can sit in the main table. Change-prone items need a date or version note. Open questions should stay out of the main answer until there is better evidence.

That process also makes updates faster. When a player reports a change, I can compare it against the current notes instead of rewriting the whole page. It is a small workflow, but it prevents the common wiki problem where old information stays visible because nobody remembers why it was added.

The current reference page I am using for this workflow is here:

https://growagardens2.com/

A simple checklist I use before updating a page:

Can this claim be checked from more than one source or direct play?
Does the page show the limits of what is known?
Are dates or version notes included where the information may change?
Is the answer easy to scan on mobile?
Would a new reader understand the next action without reading the whole page?

Small reference projects do not need heavy infrastructure. They need careful wording, repeatable checks, and a willingness to leave uncertain details unpublished until they are verified.