Two Clocks, One Promise
A support promise measured in working hours has to know when you work — in both directions. Ours knew in one, and the missing half put a Friday deadline at eleven at night.
Almost every support contract worth signing is written in working hours. "One working day" for a general enquiry, "four hours" for an outage, and the difference between those two phrasings is the whole reason the distinction exists: one of them means four hours at two in the morning and the other does not. A system that measures both against the same clock is wrong about one of them, always. We got this half right for a year and did not notice the other half was missing.
The half that worked
Each ticket category chooses its own clock. Leave it on elapsed time and a four-hour promise means four real hours, counted through the night and the weekend, which is exactly what an outage promise should mean. Switch it to working hours and the countdown stops at closing, skips the days your organization does not work, skips your public holidays, and starts again when you open.
That calendar is not ours to guess at. The working week is a setting, because it is genuinely not the same everywhere — a business whose weekend falls on Friday and Saturday is not an edge case to be handled, it is a Tuesday. The same setting already governs leave calculations and workflow due dates, so an organization answers the question once and everything downstream obeys it.
Why this is worth a whole post
Because the feature was real, shipped, tested and demonstrable, and it still produced a wrong answer the first time anybody used it in anger. A capability that is right in the demonstration and wrong in the second week is more expensive than one that was never built, because you have already stopped checking.
The half that did not
Support tickets spend a lot of their life waiting on the person who raised them. You ask a question, they are in a meeting, and the ticket sits. That time should not count against you, so the clock pauses while a ticket is waiting on its requester and the deadline moves out when it comes back.
The pause moved the deadline by the amount of real time that had passed. Not working time. Real time — the same wall clock the working-hours setting exists to stop using.
One ticket, one question asked, one deadline
Read the fourth row again, because the size of the error is not the interesting part. The deadline landed at eleven o'clock on a Friday night, on a promise whose entire purpose was to only count hours somebody is at work. An organization that switched to working hours specifically to stop getting weekend false breaches got a worse one, and got it the first time an agent asked a question — which is to say, almost immediately, and on the ticket where they were being diligent.
What it actually was
Not a rounding bug and not a calendar with a wrong holiday in it. The countdown was computed in one place and the pause was refunded in another, and only the first place had been taught about the working week. The second place did arithmetic that was correct for the older behaviour and quietly wrong for the newer one, which is what makes this class of defect survive: the wrong half is not broken, it is out of date.
The underlying cause was smaller and more general than the symptom. Our working calendar could only count forwards — give it a starting point and an allowance and it would tell you when that allowance runs out. It could not answer the opposite question, which is how much working time lies between two moments. So the code that needed to give back an interrupted allowance had no way to measure one, and did the only thing available.
The general version, which is not about helpdesks
A clock you can only count forward on is half a clock. Any system that computes deadlines against a business calendar will eventually need to measure a span against that same calendar — for a pause, a hold, a suspension, an appeal window. If only one direction exists, the other one gets written with whatever arithmetic is to hand, and it will look right for exactly as long as nobody pauses anything.
What it does now
The deadline is held as remaining time rather than as a span to refund. At the moment the clock pauses, the ticket has some amount of its allowance left; when it resumes, it gets exactly that much again, counted from now, on whichever clock its category runs. A ticket that was already past its deadline when the pause began stays past it — waiting on a requester does not un-miss a deadline you had already missed.
One property of the repair is worth stating because it is what made it safe to apply to live data: on an elapsed clock, the new arithmetic lands on the identical instant as the old. Giving back what was left, measured from now, is the same moment as pushing the old deadline out by the length of the pause. No existing ticket's deadline moved by a second. That is asserted in a test rather than believed.
The question to ask anybody, including us
Vendors demonstrate the countdown. It is the part that looks good in a demonstration — a clock that visibly stops at five and starts again at nine. Almost nobody demonstrates the pause, and the pause is where two clocks get a chance to disagree.
- Whose calendar is the working week? If it is the vendor's and not yours, the answer is already wrong for anybody whose weekend is not Saturday and Sunday.
- What happens to a working-hours deadline when a ticket waits on the customer overnight? Ask for the resulting date, not a description. A date can be checked against a calendar; a description cannot.
- Does the pause use the same calendar as the countdown? This is the actual question, and it is worth asking in exactly these words, because a system can answer yes to the first two and no to this one — as ours did.
We publish our own answers because a post that tells you to interrogate everyone else and never answers first has told you nothing. Ours are: yours, Monday 15:00, and yes — since August 2026, and not before. The measured figure in the table above is from our own test suite, and it is on this page rather than in a changelog because a claim about accuracy is worth what its worst example is worth.
