Why deadlines results differ in Singapore

The top 5 reasons results differ

Run this scenario in DocketMath using the Deadline calculator.

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.

Below are the top 5 reasons results differ:

1. **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.

2. 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.

3. **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.

4. 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).

5. 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–extend to next day registry is open, 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.

• Freeze the jurisdiction and tool settings so both runs use the same rule set.
• Compare one input at a time (dates, rates, amounts) and re-run after each change.
• Review the breakdown to see which segment or assumption drives the difference.

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., 14 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:

Then note the pattern:

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 extend to next day registry is open 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.

Next steps

1. Re-enter inputs using the “event facts” you can evidence

   • Prefer documented dates: service records, delivery acknowledgements, or system timestamps for receipt.

2. Lock your counting method

   • Decide whether your process is using calendar days or working/adjusted days, and keep that consistent across recalculations.

3. 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.

4. 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.

Related reading

• Why deadlines results differ in Canada — Troubleshooting when results differ
• Worked example: deadlines in New York — Worked example with real statute citations
• Deadlines reference snapshot for New Hampshire — Rule summary with authoritative citations