mcp-server-time leaks internal filesystem paths when timezone input exceeds 255 characters

Reproduction

Both get_current_time and convert_time leak the server's internal filesystem path when the timezone parameter exceeds 255 characters (OS NAME_MAX).

Exact boundary (macOS, NAME_MAX=255):

• timezone: "A" × 255 → clean error: "No time zone found with key AAA..."
• timezone: "A" × 256 → leaks path: "[Errno 63] File name too long: '/Users/<username>/.cache/uv/archive-v0/<hash>/lib/python3.11/site-packages/tzdata/zoneinfo/AAA...'"

What it discloses:

1. Server OS username
2. UV cache directory structure and archive hash
3. Python version (3.11)
4. Package installation path layout

Root cause: Python's ZoneInfo() constructor attempts a filesystem lookup before validating string length. When the filename exceeds OS NAME_MAX, the OS returns ENAMETOOLONG (errno 63). Python wraps this in a ZoneInfoNotFoundError whose message includes the full path. mcp-server-time catches the exception but passes its string representation to the client unfiltered.

Repro command (JSON-RPC over stdio):

echo '{"jsonrpc":"2.0","id":0,"method":"initialize","params":{"protocolVersion":"2024-11-05","capabilities":{},"clientInfo":{"name":"test","version":"1.0"}}}
{"jsonrpc":"2.0","method":"notifications/initialized"}
{"jsonrpc":"2.0","id":1,"method":"tools/call","params":{"name":"get_current_time","arguments":{"timezone":"'"$(python3 -c "print('A'*256)")"'"}}}' | uvx mcp-server-time

What IS properly handled (not vulnerable):

• Path traversal: blocked by ZoneInfo ("keys must refer to subdirectories of TZPATH")
• Null bytes: properly rejected ("embedded null byte")
• Normal invalid timezones: clean "No time zone found" error

Suggested fix: Pre-validate timezone string length (reject > 64 chars) or sanitize exception messages before returning them to the client.