Skip to main content
Glama
IBM

chuk-mcp-time

by IBM

get_time_for_timezone

Get the current time for any IANA timezone by querying multiple NTP servers for accurate UTC conversion. Supports fast or accurate modes with latency compensation.

Instructions

Get current time for a specific timezone with high accuracy.

Queries multiple NTP servers for accurate UTC time, then converts to the
requested timezone. Includes all consensus metadata and source details.

Args:
    timezone_name: IANA timezone name (e.g., "America/New_York")
    mode: Accuracy mode - "fast" or "accurate"
    compensate_latency: If True, add query duration to timestamp (default: True)

Returns:
    TimezoneResponse with time in specified timezone

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
timezone_nameYes
modeNofast
compensate_latencyNo

Implementation Reference

  • The main handler function for get_time_for_timezone tool. Uses @tool decorator from chuk_mcp_server, gets UTC consensus via get_time_utc, then converts to the requested IANA timezone using zoneinfo. Returns TimezoneResponse with local_time field. On conversion error, returns error message in local_time and appends warning.
    @tool  # type: ignore[arg-type]
    async def get_time_for_timezone(
        timezone_name: str,
        mode: AccuracyMode = AccuracyMode.FAST,
        compensate_latency: bool = True,
    ) -> TimezoneResponse:
        """Get current time for a specific timezone with high accuracy.
    
        Queries multiple NTP servers for accurate UTC time, then converts to the
        requested timezone. Includes all consensus metadata and source details.
    
        Args:
            timezone_name: IANA timezone name (e.g., "America/New_York")
            mode: Accuracy mode - "fast" or "accurate"
            compensate_latency: If True, add query duration to timestamp (default: True)
    
        Returns:
            TimezoneResponse with time in specified timezone
        """
        # Get UTC consensus first
        time_response = await get_time_utc(mode=mode, compensate_latency=compensate_latency)  # type: ignore[misc]
    
        # Convert to requested timezone
        try:
            from zoneinfo import ZoneInfo
    
            utc_timestamp = time_response.epoch_ms / 1000.0
            utc_dt = datetime.fromtimestamp(utc_timestamp, tz=UTC)
            local_dt = utc_dt.astimezone(ZoneInfo(timezone_name))
            local_time = local_dt.isoformat()
    
            return TimezoneResponse(
                **time_response.model_dump(),
                timezone=timezone_name,
                local_time=local_time,
            )
    
        except Exception as e:
            # If timezone conversion fails, add error to warnings
            warnings = list(time_response.warnings)
            warnings.append(f"Failed to convert to timezone {timezone_name}: {e}")
    
            # Get base data but exclude warnings since we're overriding it
            base_data = time_response.model_dump(exclude={"warnings"})
    
            return TimezoneResponse(
                **base_data,
                timezone=timezone_name,
                local_time=f"ERROR: {e}",
                warnings=warnings,
            )
  • TimezoneResponse model - the output schema for get_time_for_timezone. Extends TimeResponse with additional fields: timezone (IANA name) and local_time (ISO 8601 formatted time in that timezone).
    class TimezoneResponse(TimeResponse):
        """Response for get_time_for_timezone tool."""
    
        timezone: str = Field(description="IANA timezone name")
        local_time: str = Field(description="Time in the requested timezone (ISO 8601)")
  • Package-level registration: get_time_for_timezone is exported in __all__ from the chuk_mcp_time package, making it publicly accessible.
    __all__ = [
        "get_time_utc",
        "get_time_for_timezone",
  • Tests for get_time_for_timezone: test_get_time_for_timezone_valid tests with 'America/New_York', test_get_time_for_timezone_invalid tests error handling with 'Invalid/Timezone'.
    async def test_get_time_for_timezone_valid() -> None:
        """Test get_time_for_timezone with valid timezone."""
        from chuk_mcp_time.server import get_time_for_timezone
    
        response = await get_time_for_timezone(
            timezone_name="America/New_York",
            mode=AccuracyMode.FAST,
            compensate_latency=True,
        )
    
        assert response.timezone == "America/New_York"
        assert response.local_time
        assert "ERROR" not in response.local_time
        assert response.iso8601_time  # Should have UTC time too
    
    
    @pytest.mark.asyncio
    @pytest.mark.network
    async def test_get_time_for_timezone_invalid() -> None:
        """Test get_time_for_timezone with invalid timezone."""
        from chuk_mcp_time.server import get_time_for_timezone
    
        response = await get_time_for_timezone(
            timezone_name="Invalid/Timezone",
            mode=AccuracyMode.FAST,
            compensate_latency=True,
        )
    
        assert response.timezone == "Invalid/Timezone"
        assert "ERROR" in response.local_time
        assert any("Failed to convert to timezone" in w for w in response.warnings)
Behavior4/5

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

With no annotations, the description carries the full transparency burden. It reveals that it queries multiple NTP servers for accurate UTC, includes consensus metadata and source details, and mentions latency compensation. However, it omits potential caveats like network dependency or rate limits, but for a time tool, this is fairly comprehensive.

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 well-structured with a summary line, followed by detailed explanation and a docstring-style Args/Returns section. It is concise with no redundant information, every sentence adds value.

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

Completeness4/5

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

Given no output schema, the description mentions the return type (TimezoneResponse) but does not detail its fields. The tool's complexity is moderate, and the description covers the method and parameters adequately, but a fuller description of the response structure would improve completeness.

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

Parameters5/5

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

Despite 0% schema coverage, the description provides full parameter explanations: timezone_name with IANA example, mode with options ('fast' or 'accurate'), and compensate_latency with its effect. This adds significant meaning beyond the schema.

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 it gets the current time for a specific timezone with high accuracy, distinguishing it from siblings like get_time_utc (UTC) and convert_time (conversion). The verb 'Get' and resource 'time for a specific timezone' are specific and unambiguous.

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

Usage Guidelines3/5

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

The description explains what the tool does but does not explicitly guide when to use it over alternatives. While the purpose implies its usage, there are no explicit 'when-to-use' or 'when-not-to-use' statements referencing sibling tools.

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

Install Server

Other Tools

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/IBM/chuk-mcp-time'

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