Skip to main content
Glama
osteele

timezone-mcp

by osteele

timezone-mcp

timezone-mcp is a local MCP server that converts timestamps between time zones. It exposes one tool, convert_time.

The server uses IANA time zone rules, including daylight saving time at the specified instant, and returns the source, UTC, and converted times with their dates.

Agents often get date boundaries wrong

As of mid-2026, general-purpose agents often answer time zone questions confidently but incorrectly. Errors are especially common around daylight saving transitions and conversions that cross a calendar date. timezone-mcp delegates the calculation to Python's IANA time zone database and returns each date explicitly.

Related MCP server: Time MCP Server

Install

Requires uv, which installs Python for the tool if the machine does not have a suitable version. Nothing to clone: add-mcp registers the server with your agent in one command, and knows where each client keeps its config.

npx add-mcp "$(command -v uvx)" \
  --args --from --args git+https://github.com/osteele/timezone-mcp@v0.1.0 --args timezone-mcp \
  --name timezone-mcp \
  --env TIMEZONE_MCP_ALWAYS_TIMEZONES="China,Eastern" \
  --global --agent claude-code --agent codex

Every argument after the command needs its own --args. add-mcp does not split a quoted command string, so folding them into the first argument writes a command name containing spaces, without reporting an error. Drop --global to register the server for one project instead of the whole machine, and see npx add-mcp list-agents for the other clients it supports.

That writes an entry equivalent to this, which you can also add by hand to whichever file your client uses:

{
  "timezone-mcp": {
    "command": "/absolute/path/to/uvx",
    "args": [
      "--from",
      "git+https://github.com/osteele/timezone-mcp@v0.1.0",
      "timezone-mcp"
    ],
    "env": {
      "TIMEZONE_MCP_ALWAYS_TIMEZONES": "China,Eastern"
    }
  }
}

Claude Desktop keeps that file at ~/Library/Application Support/Claude/claude_desktop_config.json on macOS, under mcpServers; open it from the developer settings, and restart the app after editing. Claude Code and Codex also take it from their own CLIs:

claude mcp add --scope user timezone-mcp \
  -e TIMEZONE_MCP_ALWAYS_TIMEZONES="China,Eastern" \
  -- "$(command -v uvx)" --from git+https://github.com/osteele/timezone-mcp@v0.1.0 timezone-mcp

codex mcp add timezone-mcp \
  --env TIMEZONE_MCP_ALWAYS_TIMEZONES="China,Eastern" \
  -- "$(command -v uvx)" --from git+https://github.com/osteele/timezone-mcp@v0.1.0 timezone-mcp

@v0.1.0 pins the install to a tagged release, so a later push to main cannot change what an already-registered client runs. Drop it to track main, or raise it when a newer tag exists.

To run the server by hand, uvx --from git+https://github.com/osteele/timezone-mcp@v0.1.0 timezone-mcp waits for MCP messages on standard input, so it will appear to hang. That is what a client expects; press Ctrl-C.

Configuration

Every result carries the zones you asked for. TIMEZONE_MCP_ALWAYS_TIMEZONES adds zones that appear in every result without being requested. With no configuration, those standing zones are China and U.S. Eastern.

Set it to a comma-separated list or a JSON array:

export TIMEZONE_MCP_ALWAYS_TIMEZONES="China,Eastern"

The JSON value [] disables standing zones entirely. An empty string is rejected.

For file-based configuration, save a JSON file such as /absolute/path/to/timezone-mcp.json:

{
  "always_timezones": ["China", "Eastern"]
}

Then set its path:

export TIMEZONE_MCP_CONFIG=/absolute/path/to/timezone-mcp.json

TIMEZONE_MCP_ALWAYS_TIMEZONES takes precedence when both variables are set.

Standing and requested zones are combined, and repeated names are deduplicated after normalization. A zone is dropped from the result when its local clock time and UTC offset match the source at that instant. A Los Angeles result is dropped for a Phoenix source when both are on UTC−07:00, for example, even though their daylight saving rules differ.

Tool arguments

  • time: An ISO-like timestamp with a clock time, such as 2026-07-16 09:30, 2026-07-16T09:30:00, or 2026-07-16T09:30:00-04:00. Date-only values are rejected.

  • source_timezone: The source time zone for a timestamp without a UTC offset. Omit it when time already contains an offset.

  • output_timezones: An optional list of additional output time zones.

  • fold: 0 selects the first occurrence of an ambiguous local time, and 1 selects the second occurrence during a fall daylight saving transition. The default is 0.

Local times that do not exist during a spring daylight saving transition are rejected.

Time zone names

Any zone argument accepts an IANA name, such as America/Los_Angeles or Europe/Berlin.

Five zones also have short aliases, matched case-insensitively:

Zone

Aliases

AoE (fixed UTC−12)

aoe, anywhere on earth

Asia/Shanghai

china, beijing, shanghai, china standard time, cst china, beijing time

America/New_York

eastern, et, est, edt, us eastern, u.s. eastern, new york, eastern time

America/Los_Angeles

pacific, pt, pst, pdt, us pacific, u.s. pacific, pacific time

UTC

utc, z

That table is the whole alias set. Anything else must be a valid IANA name; an unrecognized name is rejected with unknown timezone.

AoE is Anywhere on Earth, the fixed UTC−12 offset that conference and journal deadlines are usually quoted in. It is the last place on the planet where a given calendar date is still in progress, so a deadline stated as AoE expires later than the same wall-clock time anywhere else.

Result

The result contains the resolved input, UTC time, standing zones, conversions, and date-boundary information. Selected fields from a China-to-Eastern conversion look like this:

{
  "utc": {
    "datetime": "2026-07-16T01:00:00+00:00"
  },
  "configured_timezones": [
    "Asia/Shanghai",
    "America/New_York"
  ],
  "conversions": [
    {
      "datetime": "2026-07-15T21:00:00-04:00",
      "timezone": "America/New_York",
      "abbreviation": "EDT",
      "requested_timezone": "America/New_York"
    }
  ],
  "date_boundary": {
    "source_date": "2026-07-16",
    "different_dates": ["America/New_York"]
  }
}

date_boundary.different_dates names the zones whose calendar date differs from the source, which is the case these conversions most often get wrong.

Each formatted timestamp also includes date, time, weekday, abbreviation, and utc_offset fields.

Development

git clone https://github.com/osteele/timezone-mcp
cd timezone-mcp
uv sync
uv run --frozen pytest
uv run --frozen ruff check .
uv run --frozen ty check

To point a client at a checkout rather than at the published source, replace the --from git+... argument with --directory /absolute/path/to/timezone-mcp run --no-dev, invoking uv instead of uvx.

timezone-mcp is one of a set of tools for agent sessions and the environments they run in, listed at osteele.com/software/agent-tools.

Available Tools

1 tool
convert_timeA

Convert a timestamp from a source timezone. Returns configured default timezones plus any requested additional timezones, omitting the source timezone when it would duplicate the input.

ParametersJSON Schema
NameRequiredDescriptionDefault
foldNo
timeYes
source_timezoneNo
output_timezonesNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
utcYes
inputYes
conversionsYes
date_boundaryYes
configured_timezonesYes

TDQS

A4.1/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description discloses important behavioral traits: the omission of the source timezone when it would duplicate the input, and the inclusion of configured default timezones. These go beyond a simple 'convert' and provide useful behavioral context for an agent.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence that front-loads the core action and packs in key behavioral nuances. Every phrase earns its place, with no redundancy or fluff.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Although an output schema exists, the description does not explain the 'fold' parameter, which is crucial for ambiguous times around DST transitions. It also does not clarify default behavior when source_timezone is null. The description covers main purpose but is incomplete for a nuanced conversion tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate. It indirectly explains 'time' (timestamp), 'source_timezone', and 'output_timezones' via 'requested additional timezones'. However, the 'fold' parameter is entirely unexplained, and timezone/time format details are omitted. The description adds some meaning but leaves gaps.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'Convert' and the resource 'timestamp from a source timezone', making the primary purpose unambiguous. Even without sibling tools, it distinguishes the conversion task and hints at multi-timezone output.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear context on behavior: it returns configured default timezones plus any requested additional timezones, and omits the source timezone when duplicated. This tells the agent what to expect, though it does not explicitly state when to use versus alternatives (no siblings exist).

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. 1 tool updatev0.1.0
    • First observedconvert_time

TDQS

A4.2/5.0
Disambiguation5/5

With only one tool, there is no possibility of confusion or overlap. The tool's purpose is clearly defined and unambiguous.

Naming Consistency5/5

The single tool name `convert_time` follows a clean verb_noun pattern, which is internally consistent.

Tool Count3/5

The server offers just one tool, which feels thin for a general timezone utility. While the core conversion feature is present, users might expect additional operations like timezone listing or validation.

Completeness4/5

The conversion operation is fully covered, but the surface lacks an explicit way to list available timezones or configured defaults, which would be a minor gap for a timezone-focused MCP.

Maintenance

ActivityMaintained
ResponsivenessNo issues

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

  • A
    license
    Not graded
    quality
    D
    maintenance
    A TypeScript server that provides time-related tools through the Model Context Protocol, allowing users to get current time in various timezones and convert times between different IANA timezones.
    MIT
  • A
    license
    B
    quality
    D
    maintenance
    A Model Context Protocol server that provides time and timezone conversion capabilities, enabling LLMs to get current time information and perform timezone conversions using IANA timezone names.
    2
    MIT
  • A
    license
    D
    quality
    C
    maintenance
    A lightweight MCP server that provides date and time tools, including the ability to retrieve current timestamps and parse date strings with IANA timezone support. It enables AI models to interact with the host OS clock and perform temporal calculations via stdio transport.
    3
    13
    7
    MIT
  • A
    license
    Not graded
    quality
    D
    maintenance
    A timezone-aware MCP server that converts times, looks up current local times, and finds overlapping working-hour slots for distributed teams.
    12
    MIT

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/osteele/timezone-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server