MCP Spotlight: Time MCP Server — Anthropic's Reference Implementation for IANA Timezone Conversion, DST-Aware Math, and the DateTime-Default Reference for Agents

Server: @modelcontextprotocol/server-time by Anthropic License: MIT · Tools: 2 (get_current_time, convert_time) · Transport: stdio or Docker (Python) Coverage: IANA timezone database (tzdata) — all ~400 zones, DST-aware, historical accuracy GitHub: github.com/modelcontextprotocol/servers/tree/main/src/time PyPI: mcp-server-time Docker: mcp/time · MCP Tracker: glama.ai/mcp/servers/modelcontextprotocol/time

Every cross-timezone agent eventually needs reliable time math. The naive "ask the LLM to compute the offset" approach produces inconsistent results — the model gets DST transitions wrong, doesn't know about historical zone changes, hallucinates zone names. The "give the agent nothing" approach blocks every scheduling workflow that touches multiple timezones. The naive "ship a pytz wrapper" approach duplicates the work the agent ecosystem would otherwise repeat per server.

The official Time MCP Server by Anthropic is the bridge that resolves this. 2 tools (get_current_time, convert_time), built around the IANA timezone database — the canonical, DST-aware, historically-correct source of timezone truth used by every major OS. MIT-licensed, official Anthropic-maintained.

This is the timezone-aware time-math default for AI agents in 2026. Two-tool minimalism, IANA accuracy, ubiquitous use.

The Two Tools: get_current_time + convert_time

The MCP surface is two tools. Both are unambiguous in intent; both are zero-destruction primitives.

get_current_time

get_current_time(timezone="Europe/Berlin")
  → Returns:
    {
      "timezone": "Europe/Berlin",
      "current_time": "2026-07-25T20:00:00+02:00",
      "utc_offset": "+02:00",
      "is_dst": true,
      "iana_name": "Europe/Berlin"
    }

The agent asks for the current time in any IANA timezone. The server returns the DST-aware current time (Berlin is currently in CEST, UTC+2), the offset, the DST flag, and the canonical zone name.

Without the timezone parameter, the server returns the system's local time (auto-detected):

get_current_time()
  → Returns: {"timezone": "UTC", "current_time": "2026-07-25T18:00:00+00:00", ...}

For agents running in different regions, the server reports what the local clock says — accurate to the millisecond, validated against IANA.

convert_time

convert_time(
  source_timezone="America/New_York",
  target_timezone="Europe/Berlin",
  time="14:30"
)
  → Returns:
    {
      "source_timezone": "America/New_York",
      "source_time": "2026-07-25T14:30:00-04:00",
      "target_timezone": "Europe/Berlin",
      "target_time": "2026-07-25T20:30:00+02:00",
      "delta_hours": 6
    }

The agent specifies the source timezone, the target timezone, and a time. The server does the DST-aware math and returns both times plus the hour delta.

For full datetime conversion (with date):

convert_time(
  source_timezone="America/New_York",
  target_timezone="Asia/Tokyo",
  time="2026-08-15T09:00:00"
)
  → Returns:
    {
      "source_time": "2026-08-15T09:00:00-04:00",
      "target_time": "2026-08-15T22:00:00+09:00",
      "delta_hours": 13
    }

The agent converts from one named zone to another, across dates, across DST transitions, with historical accuracy.

The IANA Timezone Database: Why It Matters

The IANA tzdata is the canonical source of timezone truth. It's the database that Linux, macOS, BSD, and most production systems use. It contains:

• ~400 named zones — Europe/Berlin, America/Los_Angeles, Asia/Tokyo, Pacific/Auckland, etc.
• Historical accuracy — every DST rule change, every zone shift, every leap-second, back to the early 1900s
• Future-forward rules — government-announced DST changes that haven't taken effect yet (e.g., countries that have announced DST abolition)
• Aliases — US/Eastern is an alias for America/New_York, GMT for Etc/GMT, etc.

When an LLM tries to do timezone math from memory, it gets these things wrong:

Failure Mode	What Goes Wrong
DST transitions	"Berlin is always +1 from UTC" — wrong in summer (+2 during CEST)
Zone aliases	"Hong Kong is +8" — correct, but the LLM might say Asia/Hong_Kong doesn't exist
Historical changes	"Moscow is +3" — wrong before 2014 (+4), wrong after 2014 transitions
Future DST changes	"Egypt reverts to standard time in 2023" — the LLM might not know
Leap years / leap seconds	Edge cases the LLM can hallucinate

The Time MCP server delegates to tzdata. The agent asks, the server computes via the canonical database. No hallucination, no approximation, no inconsistency.

The DST-Aware Math Pattern

The killer feature: DST-aware arithmetic. When the conversion crosses a DST transition, the server handles it correctly:

// Berlin switches from CEST (+2) to CET (+1) on October 25, 2026 at 03:00

convert_time(
  source_timezone="America/New_York",
  target_timezone="Europe/Berlin",
  time="2026-10-24T22:00:00"
)
  → Returns:
    {
      "source_time": "2026-10-24T22:00:00-04:00",
      "target_time": "2026-10-25T04:00:00+02:00",  // CEST still
      "delta_hours": 6
    }

convert_time(
  source_timezone="America/New_York",
  target_timezone="Europe/Berlin",
  time="2026-10-25T22:00:00"
)
  → Returns:
    {
      "source_time": "2026-10-25T22:00:00-04:00",
      "target_time": "2026-10-26T03:00:00+01:00",  // CET now
      "delta_hours": 5  // delta changed!
    }

The hour delta shifts from 6 to 5 because Berlin transitioned out of DST. The server handles the transition correctly; the agent doesn't need to know the exact DST rule.

For meetings that span DST transitions:

User: "Schedule a recurring meeting at 9 AM Berlin time, every Monday.
       What does that look like for the New York team?"

Agent:
  1. For each Monday in Q3-Q4 2026:
     convert_time(
       source_timezone="Europe/Berlin",
       target_timezone="America/New_York",
       time="09:00"
     )
  2. Pre-DST Mondays: 9 AM Berlin → 3 AM New York
  3. Post-DST Mondays: 9 AM Berlin → 4 AM New York
  4. Returns the per-week conversion

The agent produces a correct schedule across the DST transition without hardcoding the rule.

The IANA Zone List Pattern

For agents that need to know what's available:

// Some variants of the Time MCP expose a list_timezones tool
list_timezones()
  → Returns ~400 IANA zone names

The agent can verify zone names, discover aliases, and present timezones to the user.

For typical agent use cases, the canonical IANA names are the right primitive:

Region	Canonical Names
Europe	Europe/Berlin, Europe/London, Europe/Paris, Europe/Madrid, Europe/Rome
North America	America/New_York, America/Chicago, America/Denver, America/Los_Angeles
Asia	Asia/Tokyo, Asia/Shanghai, Asia/Singapore, Asia/Dubai, Asia/Kolkata
Australia	Australia/Sydney, Australia/Perth
UTC	UTC, Etc/UTC

The agent learns to use IANA names; the server normalizes aliases.

The Scheduling Workflow

The canonical agent-driven scheduling workflow:

User: "Schedule a call with the Berlin team for next Tuesday at 2 PM their time.
       What does that look like in my timezone?"

Agent:
  1. // Determine today's date and next Tuesday
     get_current_time(timezone="UTC")
     // → 2026-07-25T18:00:00+00:00 (Saturday)
     // Next Tuesday = 2026-07-28

  2. convert_time(
       source_timezone="Europe/Berlin",
       target_timezone="America/Los_Angeles",
       time="2026-07-28T14:00:00"
     )
     // → 2026-07-28T05:00:00-07:00 (5 AM LA)

  3. // That's 5 AM — too early. Suggest alternatives.
     convert_time(
       source_timezone="Europe/Berlin",
       target_timezone="America/Los_Angeles",
       time="2026-07-28T17:00:00"  // 5 PM Berlin
     )
     // → 2026-07-28T08:00:00-07:00 (8 AM LA, more reasonable)

  4. Returns: "Suggested time: 5 PM Berlin → 8 AM Los Angeles"

The agent does the math correctly across DST, suggests a time that's reasonable for both parties, surfaces the result.

The Recurring Meeting Pattern

For agents that compute recurring schedules:

User: "Compute the next 8 weeks of our standup time, Berlin 9 AM,
       what's that for each team member?"

Agent:
  1. // Get each team member's timezone (from Slack MCP or Notion MCP)
  2. // Iterate through the next 8 Mondays
  3. For each Monday:
     For each team member:
       convert_time(
         source_timezone="Europe/Berlin",
         target_timezone=member.timezone,
         time=f"{monday}T09:00:00"
       )
  4. Returns the schedule matrix

The agent produces a correct recurring schedule across DST transitions, across zones, across the team.

The Log + Timestamp Pattern

For agents that parse logs or audit trails:

User: "This Sentry error has timestamp '2026-03-29T02:30:00'. What local time was that
       for the user in Berlin?"

Agent:
  1. convert_time(
       source_timezone="UTC",
       target_timezone="Europe/Berlin",
       time="2026-03-29T02:30:00"
     )
     // → 2026-03-29T04:30:00+02:00 (4:30 AM, just after DST spring-forward)
  2. Returns: "The error occurred at 4:30 AM Berlin time, just after the DST spring-forward"

The agent converts UTC timestamps to user-local time correctly, with DST awareness.

The Cron + Schedule Pattern

For agents that compute cron schedules:

User: "Schedule a job to run at 9 AM Berlin time every weekday.
       What UTC offset should I use for the cron expression?"

Agent:
  1. // For summer (CEST): 9 AM Berlin = 7 AM UTC
  2. // For winter (CET): 9 AM Berlin = 8 AM UTC
  3. // DST-aware cron needs special handling (most cron engines don't natively)
  4. // Suggest: use TZ=Europe/Berlin in the cron, not UTC
  5. Returns: "Use the cron expression with TZ=Europe/Berlin, or split into
               summer/winter expressions"

The agent identifies the DST problem and proposes the right solution (TZ-aware cron, not UTC offset).

The Historical Timestamp Pattern

For agents that parse historical data:

User: "This invoice is dated '2020-01-15'. What timezone does it assume?"

Agent:
  1. // Historical: most timezones were similar in 2020, but some changed
  2. // Europe/Berlin in January 2020 was CET (+1)
  3. // America/New_York in January 2020 was EST (-5)
  4. // Russia was Moscow time +3 (pre-2014 it was +4)
  5. Returns: "January 2020 was standard time (winter) for Northern Hemisphere zones"

The agent uses IANA's historical accuracy for backdated events.

Facio Integration

{
  "mcpServers": {
    "time": {
      "command": "uvx",
      "args": ["mcp-server-time"]
    }
  }
}

Or via Docker:

{
  "mcpServers": {
    "time": {
      "command": "docker",
      "args": ["run", "-i", "--rm", "mcp/time"]
    }
  }
}

Facio's audit trail captures every Time MCP call with the tool, the source/target timezones, the input time, the output time, and the delta. For a regulated team (SOC2, financial compliance, scheduling audit), this is the complete time-conversion record: "Agent at 14:32 UTC converted 2026-07-28T14:00:00 Europe/Berlin to America/Los_Angeles, returned 2026-07-28T05:00:00-07:00."

For HITL workflows, the Time MCP server is read-only by design. There's no destructive surface — time conversions can't mutate external state, can't post content, can't send emails. The tool is unconditionally safe:

Tool	Severity	Suggested Gate
get_current_time	Read	None — autonomous
convert_time	Read (math)	None — autonomous

No gates required. The agent converts times as much as it wants.

The interesting HITL pattern is timezone-source allow-listing for high-stakes scheduling. Facio can be configured to:

• Allow only specific IANA zones (e.g., corporate zones only) for internal scheduling
• Block ambiguous aliases (e.g., US/Pacific — prefer America/Los_Angeles) for consistency
• Require HITL approval for historical date conversions (backdating concerns)

For multi-region setups (agents in different timezones), the system timezone is auto-detected; the agent always has accurate local time.

For multi-tenant SaaS setups, per-tenant timezone policy — one tenant allows all zones, another restricts to business zones.

Quickstart

# Option 1: uvx (Python, lowest friction)
uvx mcp-server-time

# Option 2: Docker
docker run -i --rm mcp/time

# Option 3: pip install
pip install mcp-server-time
mcp-server-time

Configuration:

{
  "mcpServers": {
    "time": {
      "command": "uvx",
      "args": ["mcp-server-time"]
    }
  }
}

First prompts:

"What time is it in Berlin right now?"
"Convert 9 AM New York to Tokyo time"
"What time was 2026-03-29T02:30:00 UTC in Berlin?"
"What's the time difference between Berlin and San Francisco right now?"
"Schedule our weekly standup at 9 AM Berlin — what does that mean for each team?"

Use Cases

Cross-timezone scheduling: "Schedule a call at 2 PM Berlin, what does that look like in LA?" Convert + reasonable-hours check.

Recurring meeting math: "Compute the next 12 weeks of our Monday standup at 9 AM Berlin, across DST." Multi-week conversion.

Log timestamp normalization: "Convert these UTC log timestamps to the user's local time in Berlin." Multi-row conversion.

Cron schedule setup: "Schedule a job at 9 AM Berlin every weekday, what's the right cron expression?" Time math + DST handling.

Event countdown: "How many hours until the Berlin product launch at 16:00 local?" Time delta + future math.

Travel time awareness: "When is 9 AM in Berlin for someone traveling from New York on Tuesday?" Convert + context.

Invoice date verification: "Verify this invoice is dated in the user's expected timezone." Conversion + validation.

Meeting room booking: "Book a 1-hour meeting in the Berlin room at 14:00 local, check it doesn't conflict with the Tokyo team's 22:00." Cross-zone conflict check.

DST transition planning: "When does our 9 AM Berlin standup shift by an hour in 2026?" DST calculation.

Multi-agent scheduling: "Three agents in Berlin, NY, Tokyo — find a 1-hour window that works for all." Multi-zone overlap calculation.

SLA tracking: "Calculate the SLA breach time in the customer's local timezone." Conversion + deadline math.

Audit trail timestamps: "Convert every timestamp in this audit log to Berlin local time." Batch conversion.

Historical timestamp parsing: "This event was on '2020-03-15 02:30 UTC', what local time was that in Moscow (which changed DST rules that year)?" Historical conversion.

Compliance deadlines: "GDPR right-to-erasure: we received the request at 14:00 UTC. When is the 30-day deadline in the requester's timezone?" Conversion + date math.

Event broadcasting: "This webinar is at 16:00 UTC. Show me the local time in 8 major markets." Multi-zone conversion.

User preferences: "User said 'in the morning', their timezone is Europe/Berlin, schedule for 9 AM local." Convert from user-local to UTC.

Holiday calendar: "When is 'New Year' celebrated in different zones (some celebrate before UTC midnight)?" Zone-aware celebration timing.

System clock verification: "Compare the system clock to NTP, verify drift." Time comparison + drift calculation.

Timestamp formatting: "Convert '2026-07-25T18:00:00Z' to 'July 25, 2026 8:00 PM Berlin'." Conversion + locale formatting.

Time-aware cron: "Set up a cron job that runs at 9 AM Berlin every weekday, even across DST." TZ-aware scheduling.

The IANA-as-Truth Pattern

The Time MCP server's defining innovation — delegate to the IANA tzdata database, never trust the LLM's memory — is the design lesson every "lookup-needed-as-MCP" server should copy.

Why IANA-as-truth wins:

• Canonical source — every major OS uses tzdata; no LLM is more authoritative
• DST-aware — handles spring-forward, fall-back, future-announced changes
• Historical accuracy — back to the early 1900s, with country-specific changes
• Alias support — US/Eastern resolves to America/New_York, etc.
• Updates — IANA releases tzdata updates as governments change rules; the server tracks them

For any MCP server that needs canonical data (time, country codes, currency, public holidays, language codes), delegate to the official source. The LLM's memory is a fallback, not a source of truth.

The Two-Tool Time-Math Pattern

The Time MCP server's second defining innovation — 2 tools covering the entire time-math domain — is the design lesson every "minimal-utility-as-MCP" server should copy.

Why two-tool minimalism wins for time:

• Single primitive — get current time, convert time
• No ambiguity — the agent doesn't have to choose between 10 tool variants
• Composability — both tools combine into any time workflow
• Universal need — every cross-timezone agent needs time math
• Easy to maintain — a minimal server is easier to audit, update, distribute

The pattern applies to:

• Calculator MCP — 1-2 tools for math
• UUID MCP — 1 tool for UUID generation
• Hash MCP — 1-2 tools for hashing
• QR MCP — 1 tool for QR code generation
• Barcode MCP — 1-2 tools for barcode generation

For any narrow utility primitive, single-tool or two-tool minimalism is the right default.

Bottom Line

The Time MCP Server is the timezone-aware time-math default for AI agents in 2026. 2 tools (get_current_time, convert_time), IANA tzdata-backed, DST-aware, historically accurate, MIT-licensed, official Anthropic-maintained.

For any agent that participates in cross-timezone workflows — scheduling, recurring meetings, log timestamp normalization, cron setup, event countdowns, SLA tracking, audit trail timestamping, historical date parsing — this is the bridge. The agent asks for the time, converts between zones, handles DST correctly, produces accurate results.

For the broader MCP ecosystem, the Time pattern is the design lesson every "lookup-needed-as-MCP" server should copy. Delegate to the canonical source + two-tool minimalism + DST-aware math. When the time primitive is right, the agent's scheduling is right.

uvx mcp-server-time (or docker run -i --rm mcp/time) and your agent has IANA-accurate time.

---

MCP Spotlight is a series covering servers that give AI agents real capabilities. Every server is evaluated for design clarity, ecosystem impact, and integration fit with Facio's HITL-first agent runtime.