Why your agent gets the time zone wrong
A customer in London asks when support is open. The agent says "until 6pm," confidently, and it is 6:30 there. Nobody wrote a bug. Somebody wrote a time with no time zone, and the model filled in the blank.
TL;DR If your prompt states clock times (open until 6pm) with no time zone, the model picks one at runtime, usually wrong for customers elsewhere. Declare the zone as a variable the caller passes and state every time against it. The checker flags the gap with prompt/naive-time.
Support prompts are full of clock times. Business hours, callback windows, same-day-reply cutoffs, after-hours escalation. They read as facts: staffed 9 to 6, reply before 5. But a clock time is only half a fact. The other half is the zone it is measured in, and prompts leave it out constantly, because the person writing the prompt knows which zone they mean and never notices they didn't say it. The model does not share that context. It has to pick a zone every single run, and it will pick one whether or not you meant it to.
§1The symptom: right number, wrong world
The failure does not look like a time-zone bug. It looks like the agent being confidently wrong about hours, SLAs, or "same day," and only for some customers. Your team, sitting in one office, tests it and everything checks out, because the model happens to guess your zone. Then a customer three time zones east gets told chat is open for another two hours when it closed at lunch their time. It is intermittent, it correlates with geography, and it is nearly impossible to reproduce from a bug report that just says "the agent gave me the wrong hours." The prompt was underspecified, and the model papered over the gap with an assumption.
§2The defect: a time with no zone
Here is the honest version of a support prompt's timing rules. Every line is a reasonable thing to want. Not one of them says whose clock.
# Role You are a support agent for a global electronics retailer. # Instructions - Live chat is staffed from 9:00am to 6:00pm. - Promise a same-day reply to any ticket that arrives before 5:00pm. - Escalate any ticket still open past 8:00pm to the on-call manager.
hours.tg:5:1 info prompt/naive-time This prompt states clock times but never fixes a timezone - the model will guess one at runtime. Declare the zone as a variable the caller can pass ("$REQUIRE variable timezone: string default to UTC") or qualify the times (9pm UTC). ✓ 1 file - 0 error, 0 warning, 1 info
§3The half-fix that breaks differently
The obvious reaction is to sprinkle in zones. Someone adds "ET" to the chat hours because that is where the team sits, and later someone else, editing the phone rules, writes "PT" because that is where they sit. Now the prompt is precise and inconsistent, which is arguably worse than vague: the model has to reconcile two different clocks in one set of rules, and any time it quotes to a customer is right in one zone and wrong in the other.
# Role You are a support agent for a global electronics retailer. # Instructions - Live chat is staffed from 9:00am to 6:00pm ET. - Phone support runs 8:00am to 8:00pm PT.
hours.tg:5:1 warn prompt/mixed-timezone Mixed timezones - this prompt qualifies times in ET and PT. Unify on one zone, or make the zone a variable ($REQUIRE variable timezone: string default to UTC) and state times against it. hours.tg:6:1 warn prompt/mixed-timezone Mixed timezones - this prompt qualifies times in ET and PT. Unify on one zone, or make the zone a variable and state times against it. ✓ 1 file - 0 error, 2 warning, 0 info
§4The fix: make the zone a variable
Both diagnostics point at the same answer, so take it. A support agent should not hard-code a zone at all, because the right zone is a property of the customer, and it changes on every conversation. Declare it once as a typed input with a sane default, then state every time against that one variable. Now there is a single source of truth for "when," the runtime fills it in per conversation, and the times read the same to a customer in London as in Los Angeles.
$REQUIRE variable timezone: string default to UTC # Role @@ role: a support agent for customers in every timezone You are a support agent for a global electronics retailer. # Instructions @@ hours: state staffed hours against the caller's zone, not the server's - Live chat is staffed from 9:00am to 6:00pm @{timezone}. @@ sla: the same-day promise is only true relative to a known zone - Promise a same-day reply to any ticket that arrives before 5:00pm @{timezone}. @@ escalate: after-hours tickets go to on-call, measured in the caller's zone - Escalate any ticket still open past 8:00pm @{timezone} to the on-call manager.
@{timezone}, a default so it never dangles. The info clears, the prompt compiles clean, and "when" now has exactly one owner.A clock time is a fact and a half. Ship the other half.
This is the same move you make for any input that belongs to the customer rather than the prompt: name it, type it, pass it in. A booking agent does it for the slot; a routing agent does it for the tier; a global support agent does it for the zone. Writing it as a variable also documents the assumption out loud, so the next person editing the file cannot quietly reintroduce a bare "5pm" without the checker noticing.
§5Common questions
- Why does my AI agent give the wrong business hours or times?
- Because the prompt states clock times with no time zone attached, so the model assumes one, often UTC or wherever it thinks 'here' is, and that assumption is wrong for any customer in another zone. Fix it by declaring the zone as a variable and qualifying every time with it.
- How do I handle time zones in a system prompt?
- Don't hard-code a single zone and don't mix two. Declare one variable ($REQUIRE variable timezone: string default to UTC) and write every clock time against it (9:00am to 6:00pm @{timezone}), so the caller passes the customer's zone at runtime and the prompt has exactly one source of truth for when.
- Does TypeGlish block a prompt that forgets the time zone?
- It advises rather than blocks: a bare clock time raises prompt/naive-time (info) and two different named zones raise prompt/mixed-timezone (warning). Neither stops the build, but both surface in check and lower the score, so the gap is visible before you ship instead of in a customer transcript.
Declaring the zone as a typed input uses the same $REQUIRE variable machinery the booking-agent walkthrough wires a tool with, and it treats "when" the way The arithmetic in your prompt treats every other number: as a real value the checker can hold, not decoration. Run tg check on your own agent prompt and see whether any time in it forgot to say whose clock.