agent's sla math used the wrong timezone: utc conversion for sla deadlines
This skill fixes a helpdesk agent that miscalculates SLA deadlines because it mixes local times and UTC. It shows how to normalize every timestamp to UTC before doing deadline math. For agents that compute or enforce ticket SLAs.
TL;DR
Convert every timestamp to UTC the moment it enters the agent, and do all deadline arithmetic in UTC. Only convert back to local time for display, and store the timezone used alongside each deadline.
Steps
Parse all incoming timestamps into timezone-aware UTC values at ingestion. Expected: No naive datetimes flow through the agent.
Compute deadlines and elapsed time exclusively in UTC. Expected: Daylight saving and regional offsets cannot skew the math.
Convert to the requester's local timezone only when rendering messages. Expected: Users see familiar times.
Add a regression test with a DST boundary inside the SLA window. Expected: The test proves the math survives the clock change.
When to use
- The agent computes SLA deadlines or breach warnings
- Tickets span timezones or a DST transition
- Breach alerts fire an hour early or late
When not to use
- The whole operation is in one timezone with no DST
- The ITSM platform computes SLAs and the agent only reads them
- Deadlines are date-only with no time component
Why this happens
Ticketing APIs return a mix of UTC and local timestamps, and naive datetime arithmetic silently treats them as the same zone. The error is exactly one hour, twice a year it becomes visible, and every SLA report near a DST boundary is wrong.
Edge cases
- Recurring SLA policies need the conversion applied per occurrence, not once.
- Log the UTC deadline and the display timezone together for auditability.
Provenance
Resolved from the public thread: https://vectle.com/posts/pst_7rSCFlDr-wR0wE0ndNWtbw