chuk-mcp-time
High-accuracy time + timezone MCP server using NTP consensus & IANA tzdata
A Model Context Protocol (MCP) server that provides extremely accurate time information by querying multiple NTP servers, removing outliers, and computing a consensus time independent of the system clock. Now includes comprehensive timezone support using IANA tzdata for accurate timezone conversions, DST handling, and timezone discovery. Perfect for applications requiring trusted time sources, timezone conversions, detecting clock drift, or working in distributed systems.
Features
π― Multi-Source Consensus: Queries 4-7 NTP servers simultaneously and computes consensus time using median with outlier rejection
β‘ Async-First: Built on asyncio for maximum performance with concurrent NTP queries
β±οΈ Latency Compensation: Automatically adjusts timestamps for query duration so returned time represents "now"
π Type-Safe: 100% Pydantic models with full type hints and validation using enums
π IANA Timezone Support: Complete timezone handling with DST, conversions, and discovery
π Clock Drift Detection: Compare system clock against trusted NTP sources
β° Timezone Conversions: Convert between any IANA timezones with accurate DST handling
πΊοΈ Timezone Discovery: List and search 600+ IANA timezones to prevent hallucination
π Transparent: Returns all source data, consensus method, error estimates, and query duration
βοΈ Configurable: Environment-based configuration for NTP servers and consensus parameters
π Production-Ready: Docker support, GitHub Actions CI/CD, Fly.io deployment
π Public Endpoint: Try instantly at https://time.chukai.io/mcp - no installation needed!
Quick Start
π Use the Public HTTP Endpoint (No Installation)
Try it instantly with our hosted MCP server:
Endpoint: https://time.chukai.io/mcp
Configure in Claude Desktop or any MCP client to connect to the HTTP streamable endpoint. No installation required!
π¦ Installation Options
Using uvx (recommended for local use)
Using pip
From source
Demo
See the server in action with a comprehensive demo:
The demo shows:
β Querying 4 NTP servers with consensus
β System clock drift detection (detects Β±millisecond accuracy)
β Timezone conversions (6 timezones from single consensus)
β Stability across 5 samples
Example output:
See examples/README.md for detailed demo documentation.
Usage with MCP Clients
Option 1: Public HTTP Endpoint (Easiest)
Connect to our hosted server at https://time.chukai.io/mcp
Claude Desktop Configuration:
Add to your claude_desktop_config.json:
β No installation required β Always up to date β High availability
Option 2: Local STDIO (Most Common)
Run locally using uvx for STDIO transport (works with Claude Desktop, mcp-cli, etc.):
Claude Desktop Configuration:
Or run manually:
Option 3: Local HTTP Server
Run your own HTTP server for testing/development:
Claude Desktop Configuration:
Available Tools
1. get_time_utc
Get current UTC time with high accuracy using NTP consensus.
Parameters:
mode(optional):"fast"(default, 4 servers) or"accurate"(7 servers)compensate_latency(optional):true(default) to adjust timestamp for query duration
Returns:
Latency Compensation: By default, the timestamp is adjusted to account for the time spent querying NTP servers. This means the returned timestamp represents "now" (when the response is sent), not when the NTP queries started. This is especially important for slow networks or accurate mode.
2. get_time_for_timezone
Get current time for a specific timezone with high accuracy.
Parameters:
timezone_name: IANA timezone name (e.g.,"America/New_York","Europe/London")mode(optional):"fast"or"accurate"compensate_latency(optional):true(default) to adjust timestamp for query duration
Returns:
Same as get_time_utc plus:
3. get_local_time
Get current time for a specific IANA timezone with high accuracy.
Uses NTP consensus for accurate UTC time, then converts to the requested timezone using IANA tzdata. Provides authoritative local time independent of system clock.
Parameters:
timezone: IANA timezone identifier (e.g.,"America/New_York","Europe/London","Asia/Tokyo")mode(optional):"fast"or"accurate"compensate_latency(optional):true(default) to adjust timestamp for query duration
Returns:
4. convert_time
Convert a datetime from one timezone to another using IANA rules.
Performs timezone conversion independent of system clock. Uses IANA tzdata to handle all DST transitions, historical changes, and political boundaries.
Parameters:
datetime_str: ISO 8601 datetime string (naive, will be interpreted in from_timezone)from_timezone: Source IANA timezone identifierto_timezone: Target IANA timezone identifier
Returns:
5. list_timezones
List available IANA timezones with optional filtering.
Returns all valid IANA timezone identifiers. Helps discover correct timezone names and prevents hallucination of invalid timezones.
Parameters:
country_code(optional): ISO 3166 country code filter (e.g.,"US","GB","FR")search(optional): Substring search filter (case-insensitive)
Returns:
Example searches:
search: "New"β Returns all timezones with "New" in the namesearch: "Tokyo"β Returns Asia/TokyoNo filters β Returns all 600+ IANA timezones
6. get_timezone_info
Get detailed information about a timezone including upcoming transitions.
Provides comprehensive timezone metadata including current offset, DST status, and upcoming transitions (e.g., DST changes). Useful for planning and understanding timezone behavior.
Parameters:
timezone: IANA timezone identifiermode(optional):"fast"or"accurate"(affects accuracy of current time)
Returns:
7. compare_system_clock
Compare system clock against trusted NTP sources to detect drift.
Parameters:
mode(optional):"fast"or"accurate"
Returns:
Status values:
"ok": Delta < 100ms"drift": Delta 100-1000ms"error": Delta > 1000ms
Configuration
Configuration can be set via environment variables or .env file:
See .env.example for complete configuration template.
How It Works
Consensus Algorithm
Query Multiple Sources: Queries 4-7 NTP servers concurrently based on mode
RTT Adjustment: Adjusts timestamps by adding half the round-trip time
Outlier Removal: Iteratively removes outliers > 5 seconds from median
Median Consensus: Computes median of remaining timestamps
Error Estimation: Calculates IQR (interquartile range) as error estimate
Latency Compensation: Adds query duration to timestamp so result represents "now"
System Comparison: Compares consensus against system clock
Latency Compensation
The server tracks how long it takes to query NTP servers and compute consensus (typically 100-500ms). By default, this duration is added to the consensus timestamp, so the returned time represents when the response is sent, not when queries began.
Example:
Query starts at T+0ms
NTP consensus computed at T+150ms β timestamp = 12:00:00.000
Latency compensation: 12:00:00.000 + 150ms = 12:00:00.150
Response sent at T+150ms with timestamp 12:00:00.150
This ensures the timestamp is as accurate as possible when received by the caller. You can disable this with compensate_latency=false if you prefer the raw consensus timestamp.
Timezone Support
The server uses Python's zoneinfo module with IANA tzdata for authoritative timezone information:
IANA tzdata Source: Uses official IANA Time Zone Database (maintained by IANA, curated by global experts)
DST Handling: Automatic daylight saving time transitions using historical and future rules
Political Boundaries: Handles all timezone changes, country boundaries, and historical adjustments
Transition Detection: Identifies upcoming DST changes and offset modifications
No System Clock Dependency: All timezone conversions use NTP consensus time, not system clock
Timezone Data Hierarchy:
UTC Authority: NTP consensus (time.google.com, time.cloudflare.com, etc.)
Political Time: IANA tzdata (official timezone database)
Local Conversion: Python's
zoneinfomoduleResult: Accurate local time independent of system clock
Default NTP Servers
time.cloudflare.com- Cloudflare's anycast NTPtime.google.com- Google's public NTPtime.apple.com- Apple's NTP servers0-3.pool.ntp.org- NTP Pool Project servers
All servers are stratum 1-2 for maximum accuracy.
Development
Setup
Testing
Code Quality
Building
Deployment
Fly.io
Docker
Architecture
Use Cases
1. Detecting Clock Drift
2. Trusted Timestamps for Logs
3. Timezone Conversions for Scheduling
4. Multi-Region Time Coordination
5. Discovering Valid Timezones
6. Planning Around DST Transitions
7. Financial/Trading Applications
Why Use This Over System Time?
Problems with System Clocks
Drift: System clocks drift over time (typically 10-50 ppm)
Virtualization: VMs can have severe time skew
Containers: Docker containers inherit host clock issues
Development: Dev machines often have incorrect time
Distributed Systems: Hard to trust time across multiple hosts
This Solution Provides
Independent Verification: Multiple external sources
Outlier Detection: Automatic removal of bad sources
Transparency: See all source data and warnings
Error Bounds: Know the accuracy of the time
Auditability: Full data for debugging time issues
Performance
Fast Mode: ~40-150ms (queries 4 servers)
Accurate Mode: ~100-300ms (queries 7 servers)
Typical Accuracy: Β±10-50ms (much better than system clock drift)
Throughput: Limited by NTP query rate (recommend caching for high-frequency use)
Latency Breakdown
NTP queries (concurrent): 20-100ms per server
Consensus calculation: <1ms
Latency compensation: Automatically added to timestamp
Total round-trip: 40-300ms depending on mode and network
Limitations
Network Required: Requires internet access to NTP servers
Latency: 100-500ms per query (not suitable for microsecond precision)
Rate Limiting: Don't query too frequently (respect NTP pool guidelines)
Accuracy: Β±10-50ms typical (good enough for most applications, not atomic clock precision)
Contributing
Contributions welcome! Please:
Fork the repository
Create a feature branch
Make your changes with tests
Run
make checkto ensure qualitySubmit a pull request
License
MIT License - see LICENSE for details
Credits
Built with:
chuk-mcp-server - High-performance MCP server framework
Pydantic - Data validation using Python type hints
NTP Pool Project servers
Support
π Issues: GitHub Issues
π¬ Discussions: GitHub Discussions
π§ Email: chris@chuk.ai
Made with β€οΈ by the Chuk AI team