SLA Business Hours and DST: Test Cases for Wall-Clock Planning

A wall-clock calculation can answer how four countable hours move through an entered 09:00-17:00 schedule. A time-zone label records the intended operating context. That is not the same as proving which UTC instant an ambiguous local timestamp represents. The current calculator deliberately does not make that second claim.

Use the result when the starting timestamp is already valid and the agreement's operating window is known. Stop when the source system reports a nonexistent or repeated local time, or when the SLA depends on event states that the calculator cannot ingest.

For an ordinary Monday 18:30 start, no time is counted after the 17:00 close. The next eligible window opens Tuesday at 09:00, so four business hours finish at 13:00. This result still depends on a policy that rolls an after-hours trigger forward rather than rejecting or timestamping it differently.

For Thursday, July 2, 2026 at 16:00, one hour is available before close. If the SLA calendar uses the source ledger's verified US national-only federal observed-closure subset, Friday July 3 is skipped, followed by the weekend. Three remaining hours run Monday July 6 from 09:00 to 12:00. The example does not claim that every service desk closes for that federal observance.

When an upstream system marks a local label as nonexistent, the expected behavior is not to silently move it forward or reinterpret it in the browser's zone. Preserve the original label, named zone, source-system message, UTC instant if available, and recorded offset. Then apply the SLA policy to the corrected event.

This guide does not state which dates or zones change in a given year because that source verification is not in the Round 2 ledger. Use the governing platform or authoritative time-zone source for that fact before calculating.

A repeated wall-clock label may refer to two different instants. Choosing the earlier or later occurrence can move a deadline even though the text input looks identical. DeadlineDays displays the zone context but does not select an offset or occurrence.

A valid audit record needs the original event timestamp with its offset or UTC equivalent. If those fields are missing, flag the case as ambiguous and send it to the policy owner rather than treating the displayed estimate as definitive.

Compare the calculator record with the service desk in this order: trigger event, target type, governing zone, operating window, break, recurring closed days, holiday layer, custom closures, permitted pause states, severity changes, and handoffs. A mismatch should be traced to the first different assumption, not corrected by adjusting the final date alone.

For a queue pause, export the event timeline and calculate each countable segment. For a regional handoff, identify whether the contract keeps one clock or changes schedules. One wall-clock window cannot infer either rule.

The only official holiday claim used in the dated test case is the US 2026 observed federal subset recorded in the source ledger and compared with the Office of Personnel Management schedule on July 28, 2026. It excludes regional, employer, bank, school, and service-provider calendars.

Report a content or source correction to [email protected] with the guide URL, test case, governing policy, expected behavior, actual behavior, and official reference. Do not send confidential ticket data.

DeadlineDays does not perform IANA instant conversion, choose DST gap or overlap resolution, ingest service-desk events, model follow-the-sun ownership, or interpret a contract. A zone label is context, not proof of a UTC instant.

The four-hour examples assume one daily window, no break unless stated, and a Saturday/Sunday weekend. Confirm the actual service schedule, pause rules, holiday scope, timestamp evidence, and policy version before relying on a deadline.