sla timer agent miscounting business hours across timezones

TL;DR

SLA timers miscount when they compute business hours in the wrong timezone: the server's, the agent's, or a single company default applied to global customers. Pin the timezone per account or per ticket, compute against that account's business-hour calendar, and handle daylight-saving transitions explicitly. Every timestamp in the pipeline must be timezone-aware; naive timestamps are the root of most miscounts.

The query

sla timer agent miscounting business hours across timezones

Use this when

• SLA timers over- or under-count across timezones
• Breach reports disagree with manual calculation
• You are designing SLA computation
• Auditing SLA accuracy

Not for

• Setting SLA targets or policies
• Writing breach notifications
• Designing holiday calendars
• Agent schedule management

Steps

1. Pin the timezone per account or ticket

Decide whose business hours govern: usually the customer's. Store the timezone on the account and use it for every SLA computation on their tickets. A single global timezone is the most common miscount source.

Expected output: a timezone pinned per account, used consistently.

2. Compute against the business-hour calendar, not wall time

Business hours mean the account's working hours: start and end times, working days, holidays. Elapsed wall-clock time is not SLA time. Implement the calendar as data, not as assumptions in code.

Expected output: SLA elapsed computed on the calendar.

3. Make every timestamp timezone-aware

Store and compare in UTC, render in local. Naive datetime objects silently mix zones and produce miscounts that look random. Audit the pipeline for naive timestamps and eliminate them.

Expected output: no naive timestamps in the SLA pipeline.

4. Handle daylight-saving transitions explicitly

On DST change days, the business day is 23 or 25 hours long. Decide the rule in advance (count actual elapsed business hours) and test both transitions. DST bugs surface twice a year and confuse everyone.

Expected output: DST transitions tested, rule documented.

5. Reconcile the timer against manual calculation regularly

Pick sample tickets monthly and hand-compute the SLA. Discrepancies reveal calendar errors, timezone misassignment, or DST bugs. Trust the reconciliation, not the timer's self-report.

Expected output: monthly reconciliation with discrepancies investigated.

Template: the checklist

SLA timezone correctness:
[ ] Timezone pinned per account, used for all computations
[ ] Business-hour calendar as data URIs hours, days, holidays
[ ] All timestamps timezone-aware, UTC in storage
[ ] DST transitions tested both directions
[ ] Monthly manual reconciliation of sample tickets

Variant phrasings

sla calculated wrong timezone

Steps 1 and 3. Pin the zone, kill naive timestamps.

business hours sla dst bug

Step 4. Test the transitions.

sla breach dispute timezone

Step 5. Reconcile manually to settle it.

Why it happens

SLA code is usually written and tested in one timezone, then deployed to a global customer base. The implicit "company timezone" assumption survives into production because tests use local fixtures. Timezone bugs are invisible in single-zone testing and obvious in production, which is why reconciliation matters more than unit tests here.

Edge cases

• Customers who travel: the pinned account timezone governs, not the customer's current location.
• 24/7 accounts versus business-hours accounts: the calendar differs per contract. Do not apply one calendar to both.
• Paused SLA clocks: "pending customer" pauses must also be timezone-aware. A pause recorded in the wrong zone miscomputes.
• Historical recalculation: changing a calendar retroactively changes past SLA results. Version calendars and note the change.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_fezU8HXaXT2Dk5HKe-evKg