Findings on what compounds and supplements do in the body, with evidence strength, quote and paper.
- Passed: Handshake
- Passed: Tools listed
- Passed: Updated recently
Median latency 699 ms · Last checked
Explore
Evidence for your next connection.
Independent measurements of remote MCP servers. Every observation has a timestamp.
Read-only probesMCP server · Other
Convert times between IANA zones and detect skipped or ambiguous DST local times.
1 failed · 7 not measured
Median of successful probes over 7 days
Share of countable probes over 30 days, including daily rollups. Auth challenges are excluded.
Tool definitions returned by this server
Independent monitoring
Responded
The server completed its last measured handshake. This is an observation, not a guarantee.
Last checked| Test area | Passed | Failed | Unmeasured |
|---|---|---|---|
ConnectionCan a client connect and discover tools? | 5 | 0 | 0 |
Reliability & speedDoes it respond consistently and quickly? | 1 | 0 | 3 |
Access & authenticationWhat is required to use this server? | 1 | 0 | 2 |
Tool qualityAre the tool definitions usable by an agent? | 4 | 0 | 0 |
Publisher identityCan the publisher be traced to its source? | 3 | 1 | 2 |
Unmeasured means there is not enough evidence to decide. How these checks work
Start using Timezone Truth
Choose your client, copy the configuration, then enable the server in your client’s MCP settings.
Run this command in your terminal, then restart Claude Code.
Claude Code
claude mcp add --transport http timezone-truth https://timezone-truth.gumballtools.com/api/mcpCapabilities
Convert a wall-clock time between two IANA timezones, and report the ways the conversion can be wrong. ALWAYS use this instead of doing the arithmetic. Timezone conversion looks like addition and is not: the mapping from a local time to an instant is not a function. - On the spring-forward date, an hour of local time DOES NOT EXIST. Asked to convert 02:30 on that date, a model will return a plausible timestamp for a time that never happens. This tool returns null and says why. - On the fall-back date, an hour happens TWICE. There are two correct answers an hour apart; this returns both rather than silently choosing. - The gap between two zones is not constant. Zones start and end daylight saving on different dates, so a cached offset is wrong for weeks each year. - Not all offsets are whole hours: India is +05:30, Nepal +05:45. Input: `time` must be YYYY-MM-DD HH:MM (or with T, and optional seconds) — free-form dates are refused rather than guessed. `from` and `to` must be full IANA names such as "America/New_York". ABBREVIATIONS ARE REJECTED, deliberately, even though most runtimes accept them. Node resolves "BST" to Bangladesh Standard Time (UTC+06:00) when nearly everyone writing it means British Summer Time (UTC+01:00) — a five-hour error that yields a perfectly plausible timestamp. Same for CST, IST, PST, and EST. Returns: the chosen UTC instant (null if the local time does not exist), every candidate instant, both zone readings with the offset and abbreviation that applied on THAT date, the difference between the zones, upcoming clock changes for both, and warnings. Check `warnings` for severity "error" before using the result.
DiscoveredRecent measurements
| Checked | Result | Response | Tools |
|---|---|---|---|
| Connected | 634 ms | 1 | |
| Connected | 563 ms | 1 |