Skip to main content
An agent can know today’s date and the current time in the session’s timezone without you adding anything to the prompt. The switch is context.current_time in the agent’s configuration, the Current date & time toggle under the time zone in the Builder. It is off for new agents and on for agents created before the switch existed. With it on, “tomorrow morning” and “next Tuesday” ground correctly from the first turn, on every channel (voice, text, and phone).
The default timezone is UTC. Change it for the agent in its configuration, and override it for a single session with timezone in the creation request. See Which timezone a session uses.

What the agent knows

With the switch on, Fish Audio injects two lines server-side: The time is refreshed on every turn, so it stays accurate through long conversations and past midnight.
Injection happens outside your configuration, so it never counts toward the system prompt’s character limit.
Both facts also exist as system variables, available whether the switch is on or off, for the cases where you want to template them yourself, for example into a webhook tool’s URL: {{system.today}} is the date at session creation as ISO YYYY-MM-DD, and {{system.timezone}} is the resolved IANA name (UTC when nothing resolves). There is no {{system.now}}: variables render once, when the session is created, so a templated clock would freeze at the opening. The per-turn time above is the one to rely on.

Which timezone a session uses

The timezone is resolved once, when the session is created, taking the first that applies:
  1. timezone in the creation request: your explicit per-session choice, as an IANA name like Asia/Tokyo. An invalid name rejects the request with 422.
  2. The agent’s configured timezone: set on the agent in the Builder (Configuration → Timezone) or via the agent config API. Pin one when your agent serves a single region regardless of who calls.
  3. client_timezone: a hint with the end user’s browser timezone, sent automatically by the Web SDK in public-agent mode. Used only when neither of the above is set; an invalid hint is ignored rather than failing the session.
  4. The caller’s phone number: inbound calls infer the timezone from the caller’s country when that country has a single timezone.
  5. UTC otherwise.
In the browser, this means zero configuration: the SDK detects the visitor’s real timezone and the agent talks about “today” in the user’s local terms, not yours. With authenticated sessions, the SDK’s automatic hint doesn’t apply. Your backend creates the session, so set timezone (or forward the browser’s value as client_timezone) in the creation request:
API (curl)
Phone-number inference is country-level only. Countries that span several timezones (the US, Canada, Australia, Russia, Brazil) are skipped. Set the agent’s timezone for those. Calls that resolve nothing run in UTC.

Turn it on or off

For the whole agent, switch Current date & time in the Builder (Configuration, under the time zone) or set context.current_time through the config API. This is the default for every session of the agent on every channel, and the only switch for phone calls, which the platform creates without a session request. Publish the agent for the change to reach live traffic. Turn it off again when the agent must not know the real date and time: a role-play agent set on a fictional date, a prompt that states its own date, or a test that must be reproducible. For one session, send context.current_time when creating it. An explicit value overrides the agent’s setting in either direction: false withholds the date and time from an agent that has them on, true injects them for one session of an agent that has them off. The older world_context field (worldContext in the SDK) is still accepted as an alias.

Going further

Authenticated sessions

All session-creation parameters, including timezone and context.

Dynamic variables

Personalize the rest of the prompt at session creation.