A time is shown in the wrong zone
Records store an unambiguous instant; every surface then renders it in a zone of its own choosing. A screen uses the browser's zone, a phone commitment is resolved in the line's zone, and business hours belong to the line as well. A reading that looks wrong is nearly always a surface disagreement rather than a stored value that is out.
Which zone each surface uses#
| Surface | Zone it uses | Consequence |
|---|---|---|
| A stored record | One absolute instant | Two people in different countries are looking at the same moment |
| A screen | The browser's own zone | Colleagues abroad legitimately see different clock readings for one event |
| A promised call-back | The line's zone | 'Tomorrow at 11' means eleven where the line is, not where the caller is |
| Business hours and after-hours behaviour | The line's configuration | A call after hours is decided by the line's clock, whoever is ringing |
| The public API | Documented with the API itself | Integrations should read that rather than infer a zone from a screen |
The commitment case is the one that surprises people, so it is worth being exact. Words spoken on a call — 'in ten minutes', 'tomorrow 11am', 'Friday 3pm', 'today evening' — are turned into a due time in the line's timezone. When nothing usable was said, the commitment lands at 11:00 the following day rather than being invented from context.
Causes, most likely first#
- Two surfaces, two zones. The screen is showing the browser's zone and the commitment was resolved in the line's. Both are correct and they differ by the offset between them.
- The line's zone is not the business's. Everything phone-related follows the line, so a line configured for the wrong region moves hours, call-backs and after-hours behaviour together.
- A caller in a different country. Nothing translates a spoken time into the caller's own zone; it is interpreted where the line is.
- A summer-time change. An offset is not a zone. A commitment made before a changeover and due after it is correct at the zone level and looks an hour out if you reason in fixed offsets.
- A genuinely wrong instant. The rarest, and the one worth escalating — visible as a commitment that fires consistently early or late for everybody rather than differently for different viewers.
What Connect completed#
The moment was recorded unambiguously and the commitment was scheduled against it. On a call, the words were also checked against what the caller actually said: a commitment whose time shares no time word with the caller's most recent time-bearing sentence is refused unless the caller has just agreed to a time the voice said aloud, and the refusal is explicit so the model cannot claim a booking that does not exist. Where the caller neither named a time nor agreed to one, a read-back is asked for.
What Connect did not complete#
It did not convert a spoken commitment into the caller's own zone, and it does not annotate a displayed time with the zone it was resolved in. It also does not tell a caller which zone it means: the closed-line message played to somebody ringing outside hours is deterministic and deliberately carries no hours in it, because an announced opening time that was wrong for the listener would be worse than none.
What you can do#
Compare the same record on two devices in different zones.
Result If they differ by exactly the offset between those zones, the stored instant is right and the rendering is doing its job.
Check the line's configured zone before changing anything else.
Result Hours, call-backs and after-hours refusals all move together with it, so this one setting explains most phone-side confusion.
On calls that cross borders, say the zone in words.
Result A spoken time is interpreted where the line is, so naming the zone is the only thing that makes the commitment unambiguous to the person on the other end.
If a call-back was promised and no commitment exists, read the call record rather than assuming a zone bug.
Result A refused commitment is recorded as refused. That is a different problem from one scheduled at the wrong hour.
What an administrator can do#
- Set the line's zone to the business's own, not to wherever the infrastructure happens to be. Everything phone-side inherits it.
- Check the hours on the line's routing row when after-hours behaviour looks wrong; the hours and the zone are configured in the same place and are wrong together more often than separately.
- For an integration, point the developer at the API's own documented handling of time rather than at a screen — a screen is rendering in somebody's browser zone and is not the contract.
When to escalate#
Escalate when the same commitment fires at the wrong moment for everybody, in every zone. That is a stored instant being wrong, which is a defect. A reading that differs between two viewers, or between a screen and a line, is a rendering difference and belongs in the checks above.
Questions#
Whose zone does 'tomorrow at 11' mean on a call?
The line's. Spoken words are resolved into a due time in the timezone the line is configured for, so a caller abroad and the business will hear the same sentence and mean different moments unless the zone is said aloud.
Why did a promised call-back not get scheduled at all?
Because it did not match what the caller said. A commitment whose time shares no time word with the caller's latest time-bearing line is refused outright, unless the caller had just agreed to a time the voice proposed. The refusal is deliberate: a booking nobody made is worse than no booking.
Does the after-hours message tell the caller when the business opens?
No. The closed-line message is deterministic and carries no hours, so it cannot announce an opening time that is wrong for the caller's zone or out of date.