Why deadlines results differ in Singapore
5 min read
Published April 8, 2026 • By DocketMath Team
The top 5 reasons results differ
If your DocketMath deadline output in Singapore (SG) doesn’t match what you expected, the mismatch is usually traceable to one of a handful of inputs or rules. This quick diagnostic targets the most common causes when calculating procedural or notice-related dates.
Pitfall: A “deadline” is not just a date—it’s typically a rule applied to a particular event date (service, receipt, filing) using specific counting conventions (including weekends/holidays). If you feed the tool the wrong event date—even with the right rule—the result can move.
Below are the top 5 reasons results differ:
Wrong event date (trigger)
- Example: using the date you sent a document instead of the date it was served (or deemed served) can shift the entire calculation.
- Common culprits: email sent vs. email received; posting date vs. service date.
Service/receipt assumptions
- “Service” and “receipt” can involve multiple factual dates in real workflows (e.g., delivery, acknowledgement, system timestamp).
- If your workflow treats “acknowledged receipt” differently than your expectation, you’ll see a consistent offset.
Counting convention errors (days vs. working days)
- Many time periods are effectively treated as calendar days, while others behave like working days (weekends/holidays excluded or handled differently).
- If you selected the wrong counting mode in your process, results can diverge even when the trigger date is correct.
Edge-case handling at month/year boundaries
- Deadlines calculated from dates near the end of a month can shift by a day (or more) when the target month has fewer days.
- This is noticeable around February, leap years, and end-of-month events (e.g., 28th–31st).
Manual adjustments that double-count (or skip) holiday logic
- A common pattern: calculate the deadline, then manually “move it off” a weekend/holiday—and also let the tool apply holiday/weekend adjustment again.
- Symptom: your output differs by roughly 1–3 days, often around long weekends or public holidays.
How to isolate the variable
Use a quick elimination approach. The goal is to identify which input or rule is different—not to guess.
Step 1: Confirm the 3 fields that drive almost every outcome
In DocketMath’s deadline workflow, verify these inputs one by one:
- Trigger event date (the event the period starts from)
- Period length & unit (e.g., 7 days, 14 days; and whether it’s treated as calendar vs. working)
- Adjustment logic (how weekends/public holidays are handled)
Cross-check each against the source you’re using (your instruction text, email chain, or the form you filled).
Step 2: Run “single-variable tests”
Change only one input at a time and watch how the output changes.
Use this checklist:
- Keep the trigger date constant; change only the counting convention.
- Keep the counting convention constant; change only the trigger date by ±1 day.
- Keep everything constant; change only the adjustment mode (if your workflow allows it).
Then note the pattern:
| What you changed | What you’ll typically see if it’s the issue |
|---|---|
| Trigger date | Entire deadline shifts by the same offset (often mirroring the trigger change) |
| Counting convention | Divergence grows when weekends/holidays fall within the interval |
| Adjustment / double-counting | Off-by-1 or off-by-2 around weekends/public holidays |
| End-of-month boundary | Noticeable jumps around month length differences (28/29/30/31) |
Step 3: Compare against your expected “intermediate steps”
If you expected a deadline on a certain date, identify what your workflow assumes for the intermediate dates:
- Day 1 start rule: does the trigger day count as Day 1, or does the day after the trigger count?
- Weekend/holiday handling: does your process exclude weekends/holidays during the count, or adjust only the final date?
Even when the final date is off, the shape of the error (consistent offset vs. weekend-triggered drift) points to the variable that changed.
Step 4: Use DocketMath as the baseline
When you’re ready, run your scenario directly in DocketMath and compare:
- Your expected deadline
- DocketMath deadline output
- The difference in days (e.g., “DocketMath is 2 days earlier”)
Then check whether that difference matches one of these common explanations:
- a one-day trigger shift,
- a counting mode swap,
- or holiday/weekend adjustment around a specific weekend/public holiday.
If you want to start immediately, use the primary tool entry: /tools/deadline.
Note: This is general diagnostic guidance. If your instruction text doesn’t specify whether weekends/holidays are excluded during the count (or only adjusted at the end), two plausible methods can produce different—but still internally consistent—dates. Align your counting convention with the instruction wording and the event-date source you can evidence.
Next steps
Re-enter inputs using the “event facts” you can evidence
- Prefer documented dates: service records, delivery acknowledgements, or system timestamps for receipt.
Lock your counting method
- Decide whether your process is using calendar days or working/adjusted days, and keep that consistent across recalculations.
Avoid re-adjusting
- If DocketMath already applies weekend/holiday adjustment, don’t also manually move the date—unless you’re intentionally applying a different rule.
Create a simple audit note for future checks
- Example: “Deadline computed from [trigger] using [unit/counting] with [adjustment] = [result].”
If you want the fastest path to resolution: run your exact scenario in DocketMath via /tools/deadline, compare the result to your expectation, then apply the single-variable test above to confirm which input/rule is causing the shift.