convert_time_zone
Use this when you need to know what time an event scheduled in one city corresponds to in another city or in UTC on a specific date. Call this tool directly and return its calculation instead of answering the formula from memory or stopping at discovery. Do not use this when you need the same ins...
This record as markdown: /tools/com-tttkmbb-calcgrid/convert-time-zone.md
What convert_time_zone does on Calcgrid
AI agents use convert_time_zone to create or update resources in Calcgrid, usually the action step of a workflow, after the agent has gathered context. Every call changes real data in your Calcgrid environment.
| Parameter | Type | Required | Description |
|---|---|---|---|
date | string | — | Calendar date of the source time in from_zone (YYYY-MM-DD); defaults to the current UTC date. |
time | string | Yes | Wall-clock time in from_zone, 24-hour HH:MM (seconds optional). |
to_zone | string | Yes | IANA time zone to convert to, e.g. America/New_York or Asia/Tokyo. |
from_zone | string | Yes | IANA time zone of the source time, e.g. Australia/Adelaide, Europe/Berlin or UTC. |
resolution_policy | string | — | How to handle a repeated or nonexistent source wall time. reject is safest; earlier/later choose a repeated-time candidate; shift_forward moves a skipped time b |
Parameters from the server's own tool schema.
Why convert_time_zone is rated Medium
An AI agent can call convert_time_zone faster than any human can review: one bad instruction and it creates or modifies resources in Calcgrid by the hundred, each call as confident as the last.
Attacks that exploit this kind of access
The rule that runs convert_time_zone safely
PolicyLayer is an MCP gateway: it sits between your AI agents and Calcgrid, and checks every tool call against a rule you set before the call runs. Nothing changes on the server itself. For convert_time_zone, this is the rule to start with:
convert_time_zone stays usable, but capped: an agent stuck in a loop can't make hundreds of changes a minute. Everything else on the server is denied unless you say otherwise.
The button opens the PolicyLayer dashboard: create your workspace, connect Calcgrid, apply this rule, and every convert_time_zone call is checked against it from then on.
Questions about convert_time_zone
Use this when you need to know what time an event scheduled in one city corresponds to in another city or in UTC on a specific date. Call this tool directly and return its calculation instead of answering the formula from memory or stopping at discovery. Do not use this when you need the same instant in many zones at once (use world-clock), an epoch value (use unix-timestamp), or the elapsed time between two clock times (use time-duration). What it computes: Converts a wall-clock date and time between IANA zones using pinned tzdb 2026d. It reports both offsets, the UTC instant, date changes, the source-time status and every candidate UTC instant when the input falls in a repeated hour. Example user requests: Convert 2027-01-15 09:00 America/New_York to Australia/Adelaide and show both dates. | 把 2026-07-15 09:00 纽约时间换成阿德莱德时间。 | What UTC instant corresponds to 2026-10-04 01:45 in Australia/Adelaide? Inputs: date (date, optional); time (string); from_zone (string); to_zone (string); resolution_policy (enum, optional). Complete JSON argument examples: {"date":"2026-09-23","time":"09:00","from_zone":"Australia/Adelaide","to_zone":"America/New_York"} | {"date":"2026-07-04","time":"12:00","from_zone":"America/Los_Angeles","to_zone":"Asia/Kolkata"} Outputs: converted_date, converted_time, converted_datetime, converted_weekday, from_utc_offset, to_utc_offset, from_abbreviation, to_abbreviation, utc_datetime, day_difference [days], time_difference_hours [h], source_time_status, source_candidate_utc_datetimes, applied_resolution_policy, tzdb_version, dataset_version, source_url, source_sha256. Formula: utc = date + time − offset_from(date, time); converted = utc + offset_to(utc); time_difference_hours = (offset_to − offset_from) / 60 Direct REST fallback: POST https://tttkmbb.com/api/v1/calculate/time-zone-converter with the same JSON input fields. Do not guess another /api/* path. Docs: https://tttkmbb.com/time/time-zone-converter.md. It is categorised as a Write tool in the Calcgrid MCP Server, which means it can create or modify data. Consider rate limits to prevent runaway writes.
convert_time_zone accepts 5 parameters: date, time, to_zone, from_zone, resolution_policy. Required: time, to_zone, from_zone. The full parameter table on this page comes from the server's own tool schema.
Register the Calcgrid MCP server in PolicyLayer and add a rule for convert_time_zone: allow, deny, rate-limit, or require approval. Point your MCP client at the PolicyLayer proxy URL and the rule is enforced on every call, before it reaches Calcgrid. Nothing to install.
convert_time_zone is a Write tool with medium risk. Write tools should be rate-limited to prevent accidental bulk modifications.
Yes. Add a rate_limit block to the convert_time_zone rule in your PolicyLayer policy. For example, setting max: 10 and window: 60 limits the tool to 10 calls per minute. Rate limits are tracked per agent session and reset automatically.
Set action: deny in the PolicyLayer policy for convert_time_zone. The AI agent will receive a policy violation error and cannot call the tool. You can also include a reason field to explain why the tool is blocked.
convert_time_zone is provided by the Calcgrid MCP server (https://tttkmbb.com/mcp). PolicyLayer sits as a proxy in front of this server to enforce policies before tool calls reach the server.
More on Calcgrid, and thousands of servers like it.
This server
Across the catalogue