Time Conversion

Workflow

1. Connectivity probe — call get_current_time with timezone UTC as the first action. If it fails, stop immediately and report: "Time conversion MCP server is unavailable. Cannot proceed."
2. Resolve timezone names — map any city names, abbreviations, or UTC offsets in the user's request to canonical IANA names before calling the tools.
3. Select the right tool:
   • Use get_current_time for "what time is it now in X?"
   • Use convert_time for "convert HH:MM from X to Y"
4. Handle multi-timezone requests — call convert_time (or get_current_time) once per target timezone; batch results into a single response table.
5. Report using this structure:
   • Result: converted time(s) with timezone name and UTC offset
   • DST note: flag if a DST transition is relevant to the result (e.g., clocks change within the next week)
   • Reference: IANA names used, for verification

Usage Examples

Current Time in a City

time-conv What time is it now in Tokyo?

Basic Conversion

time-conv Convert 3:00 PM EST to Tokyo time

Multi-Timezone Meeting

time-conv What time is 10 AM New York in London, Tokyo, and Sydney?

ISO Timestamp Conversion

time-conv When is 2026-02-15 00:00 UTC in America/Los_Angeles?

DST Awareness

time-conversion Is Europe/London currently on GMT or BST?

Configuration

MCP server is called time and is configured in .copilot/mcp-config.json. No sensitive environment variables are required for this skill.

Best Practices

• Always use IANA timezone names — abbreviations like EST, BST, IST are ambiguous and should be resolved to IANA names before calling tools
• Always run a connectivity probe (get_current_time UTC) before executing the user's request
• Prefer convert_time over manual offset arithmetic — let the MCP server handle DST automatically
• Present results in a table when converting to multiple timezones simultaneously
• Flag DST transitions when a conversion date falls near a clocks-change boundary

Limitations

• Relies on the IANA timezone database; historical timezone changes before database coverage may be incomplete
• Future DST rule changes (e.g., countries abolishing DST) take effect only after a database update
• Cannot perform calendar arithmetic (adding/subtracting days or weeks) — use general reasoning for that
• UTC offsets (e.g., +05:30) are accepted but treated as fixed — DST is not applied when using raw offsets