agent's sla timer miscalculated across timezones: business-hours clock

TL;DR

An agent's SLA timer miscalculates when it counts wall-clock time instead of the account's business hours, or computes in the wrong timezone. Mirror the helpdesk's rules exactly: pin the account timezone, count only business hours on the business calendar, and reconcile the agent's numbers against the helpdesk's regularly. The agent's clock must agree with the system of record, not just with itself.

The query

agent's sla timer miscalculated across timezones: business-hours clock

Use this when

• Agent SLA numbers disagree with the helpdesk
• Breach predictions are wrong across timezones
• You are building agent SLA logic
• Auditing timer accuracy

Not for

• Setting SLA targets or policies
• Configuring helpdesk SLA rules
• Agent shift scheduling
• Holiday calendar design

Steps

1. Pin the timezone per account, matching the helpdesk

Use the same timezone the helpdesk uses for that account's SLA: usually the customer's. If the agent computes in UTC or the server zone while the helpdesk uses the account zone, every number disagrees. Parity starts with the pin.

Expected output: account timezone pinned identically to the helpdesk.

2. Count business hours, not wall-clock elapsed

SLA time is business hours on the account's calendar: working days, working hours, holidays excluded. An agent counting raw elapsed time over a weekend will cry breach on Monday morning while the helpdesk shows green. Implement the calendar, not the stopwatch.

Expected output: business-hour computation on the account calendar.

3. Make every timestamp timezone-aware

Store and compare in UTC, convert for display. Naive datetimes silently mix zones and produce miscalculations that look random. Audit the agent's time handling for naive timestamps and eliminate them.

Expected output: no naive timestamps in the timer path.

4. Reconcile agent timers against the helpdesk regularly

Sample tickets and compare the agent's remaining-time figures to the helpdesk's. Discrepancies reveal calendar mismatches, wrong pins, or DST bugs. The helpdesk is the system of record; the agent must agree with it.

Expected output: periodic reconciliation with discrepancies investigated.

5. Handle DST transitions explicitly

On changeover days the business day is 23 or 25 hours. Test both transitions against the helpdesk's behavior and match it. DST bugs surface twice a year and confuse every timezone-sensitive calculation simultaneously.

Expected output: DST behavior tested and matching the helpdesk.

Template: the checklist

Agent SLA clock correctness:
[ ] Account timezone pinned, matching the helpdesk
[ ] Business-hour computation on the account calendar
[ ] All timestamps timezone-aware, UTC in storage
[ ] Regular reconciliation against the helpdesk
[ ] DST transitions tested both directions

Variant phrasings

agent sla wrong timezone

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

sla breach miscalculated agent

Steps 2 and 4. Business hours plus reconciliation.

business hours timer bug

Steps 2 and 5. Calendar computation plus DST.

Why it happens

Agent SLA logic gets written quickly ("hours since created") while the helpdesk's SLA engine encodes years of business rules: calendars, zones, holidays, pauses. The agent's naive timer and the helpdesk's real timer answer different questions, and the agent presents its answer with confidence. The fix is not a better timer; it is the same timer as the helpdesk.

Edge cases

• Paused SLA clocks: "pending customer" pauses must use the same timezone-aware logic. A pause in the wrong zone miscomputes.
• Multi-region accounts: one account with teams in several zones needs an explicit governing zone. Do not average.
• The helpdesk changing its calendar: calendar updates must propagate to the agent's copy. Version and sync calendars.
• Sub-hour precision: rounding differences between agent and helpdesk cause off-by-one disputes. Match the rounding rule.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_YFJaghcZynczeJiCz5R1kg