Methodology

Inputs and calculation order

A reproducible calculation starts by recording the tool, requested date or range, direction, amount, country, time zone when relevant, and the selected calculation mode. DeadlineDays then follows a deterministic processing order: normalize those inputs, establish the start and end boundaries, apply the chosen inclusion rule, evaluate recurring non-working weekdays, apply available public-holiday records, merge custom closures, and perform any stated final-date adjustment. A later layer never silently changes an earlier choice. If a required value is absent, unavailable, or outside a tool's supported range, that condition belongs in the result status rather than being replaced with an unstated default. This order lets a reviewer separate an input disagreement from a calendar-data disagreement and repeat only the layer that needs attention.

• Business Days Calculation Rules

Day 0, day 1, and boundary inclusion

Day 0 and day 1 describe a boundary decision, not a universal property of a date. When a rule excludes the trigger date, that date is day 0 and counting begins with the next eligible date. When a rule includes it, the same date can be day 1 only if it survives the applicable non-working-day layers. Range tools ask a separate question about whether the ending boundary belongs in the count. Moving a result that lands on a closed day is also separate from deciding which day started the period. DeadlineDays exposes these choices because phrases such as "within five business days," "five days after," and "through Friday" can produce different outcomes. Record the selected boundary inclusion rule beside the result and compare it with the contract or policy wording before treating a date as binding.

• Business-day boundary rules

Recurring weekends and non-working weekdays

The recurring layer represents weekdays that the relevant operation does not normally process. Saturday and Sunday are common defaults, but they are not a universal weekend and should not be inferred from a country name alone. A warehouse, support queue, payroll provider, bank, customer, or public office may use a different weekly operating pattern. DeadlineDays evaluates the selected recurring weekdays consistently across the requested range before one-off holiday and closure dates are considered. If a date matches both a recurring rule and another exclusion, it is excluded once. This layer is intentionally date based: it does not model partial shifts, rotating rosters, on-call coverage, cutoff hours, or capacity reductions. Use the calendar of the operation responsible for the deadline, document its weekly pattern, and escalate mixed-hour SLA questions to the dedicated limitations and test-case materials.

• SLA Deadline Limitations

Public-holiday sources and status

The public-holiday layer is both a date set and a status statement about that set. Holiday-aware tools request data for the selected country and year, identify the provider used by the calculation, and distinguish available records from unavailable or scope-incomplete coverage. A successful response does not prove that every regional, bank, school, market, employer, or temporary closure is present. Likewise, an official annual list can change after publication or apply only to a stated worker or institution scope. The public-holiday source, country, year, and visible status therefore travel with the result. When coverage is unavailable, the calculator must not imply that the period contains no holidays. Compare important dates with the linked official source and preserve the status that was shown when the result was produced.

• Holiday Data Sources & Review Dates

Holidays and custom closures

Custom closures add dates that a shared public calendar cannot know, such as an inventory shutdown, employer holiday, customer blackout, provider maintenance day, or locally observed closure. They are applied after the recurring weekday and public-holiday layers, then deduplicated by date so one closure cannot remove two business days merely because it appears in two sources. A custom date is user-supplied evidence, not an official holiday designation, and its label should describe the operational reason without being mistaken for source verification. Full-day custom closures are also a poor substitute for half days, changing shifts, or hourly SLA pauses. Before relying on a result, compare the entered list with the responsible organization's current notice and retain the list outside the site when the calculation forms part of an audit or approval record.

Reproducibility and checks

Result reproduction requires more than saving the final date. Keep the calculator route, input dates and times, direction or duration, inclusion setting, selected non-working weekdays, country and year, holiday toggle and status, custom closure dates, adjustment rule, time zone, and the date on which the calculation was reviewed. Where the result exposes skipped dates or a workflow explanation, retain that evidence as well. This evidence retention makes a later review possible without guessing. A share link may preserve approved bounded settings, but it is not a private case file and may omit user-entered text, so critical evidence belongs in the organization's own record. Re-enter the saved assumptions in the same tool and compare the intermediate exclusions before comparing the endpoint. If the endpoint differs, identify whether input normalization, calendar evidence, or a changed policy caused the difference instead of overwriting the earlier result.

Testing strategy and regression fixtures

DeadlineDays tests deterministic date arithmetic with fixed regression fixtures that state the input, expected boundary behavior, excluded dates, and expected result. Fixtures cover ordinary ranges as well as month and year boundaries, reverse movement, duplicate closures, empty or unavailable holiday responses, business-hour edges, and time-zone-sensitive scenarios where the relevant tool supports them. Publication tests separately check that explanations, source status, accessible evidence, locale pairs, routes, canonicals, and navigation survive the static build. These tests detect a code or publication regression; they do not certify a contract interpretation or prove that an external calendar remains current. When a reported result reveals a new calculation defect, the correction should add the smallest fixture that reproduces it, then re-run related fixtures so a local fix cannot quietly change another workflow.

• SLA business-hours and DST test cases

Known limits and official-source escalation

DeadlineDays is a planning and independent-checking tool. It does not decide which contract controls, whether a notice was legally effective, when an approval actually occurred, which employer policy applies, or whether a local closure binds a counterparty. It also cannot infer regional observances, provider cutoffs, partial operating days, rotating shifts, service-desk pause events, or later source amendments that are outside the selected data. Official-source escalation is required when a date affects a filing, payment right, employment action, tax treatment, regulated notice, or another consequence for which an incorrect assumption matters. Check the current government or agency publication, the signed contract and policy version, the responsible organization's operating calendar, and qualified professional advice where interpretation is needed. Record any difference from the calculator as an explicit override rather than changing the inputs until the preferred answer appears.

• SLA Deadline Limitations