What can you do with this server?

This MCP server provides time-conversion and Chinese calendar/DST utilities. * Convert a clock date/time at a given longitude into local true solar time, including longitude correction, equation of time, UTC offset, and China 1986–1991 DST handling. * Configure true-solar-time conversion with optional DST mode (auto/boolean), equation-of-time method (precise/simple), latitude, and UTC offset. * List all 24 solar terms for a Gregorian year with exact UTC and Beijing times, or query one term by Chinese or English name. * Return the full China daylight saving time table for 1986–1991, or determine the DST status of a specific clock time.

fateclear-solar-time

by xiaoyu312

Overview Schema Source Related Servers Discussions Admin

TypeScript

Remote

简体中文 · English · 日本語

fateclear-solar-time

把钟表时间与经度换算成当地真太阳时，并查看每一步修正。

面向历法应用、时间换算工具和 AI 助手的小型 TypeScript 库。输入日期、钟表时间、经度与时区偏移，获得真太阳时、经度修正、均时差和夏令时状态；也可以查询二十四节气时刻。附带 MCP 服务。

License: MIT

由拨云 FateClear 维护 · 在线排盘入口 · X 项目更新

先看输入与结果

安装后，在支持 ESM 的 TypeScript 项目中调用：

import { trueSolarTime } from "fateclear-solar-time";

const r = trueSolarTime({
  year: 1990, month: 3, day: 12,
  hour: 23, minute: 30,
  longitude: 116.4,
});

r.longitudeCorrectionMinutes; // -14.4
r.dstCorrectionMinutes;       // 0
r.trueSolarText;              // YYYY-MM-DD HH:mm:ss
r.equationOfTimeMinutes;

默认标准时区偏移为 UTC+8。东经 116.4° 相对该时区的经度修正为 116.4 × 4 − 8 × 60 = −14.4 分钟，再叠加当天的均时差，得到当地真太阳时。结果同时保留分项修正，便于应用说明换算过程。

示例沿用仓库已有的公开日期，用于说明 API。完整返回类型见 src/solar-time.ts。

Related MCP server: Chinese Fortune Analysis System (BaZi)

最短接入方式

需要 Git、Node.js 18 或更新版本、npm，以及支持 ESM 的项目。

npm install github:xiaoyu312/fateclear-solar-time

这里使用 GitHub 源码安装方式；安装过程会通过 prepare 编译 TypeScript，需要能够安装声明的依赖。已发布 v0.1.0，该版本没有额外下载附件。只想体验生日排盘与真太阳时展示，可直接打开 FateClear。

核心能力

入口	输入与结果
`trueSolarTime`	钟表日期时间、经度和选项 → 当地真太阳时、平太阳时、UTC、各项分钟修正和 DST 状态
`solarTerms` / `solarTerm`	公历年，或年份与节气名 → 二十四节气时刻；名称支持简体、繁体和英文
`chinaDstStatus` / `CHINA_DST`	中国钟表时间 → 夏令时状态；或读取 1986–1991 年的六年起止表
MCP 服务	通过 stdio 向兼容客户端提供以上换算和查询能力

库的用法与参数

import { trueSolarTime, solarTerms, solarTerm, chinaDstStatus } from "fateclear-solar-time";

trueSolarTime({
  year: 1988, month: 7, day: 1,
  hour: 12, minute: 0, longitude: 120,
}).dstCorrectionMinutes; // -60

solarTerms(2026).length; // 24
solarTerm(1990, "立春").beijing;
solarTerm(1990, "Start of Spring").utc;

chinaDstStatus({
  year: 1990, month: 9, day: 16, hour: 1, minute: 30,
}); // "ambiguous"

trueSolarTime 参数：

参数	说明
`year` / `month` / `day` / `hour` / `minute`	钟表记录的公历日期和时间；月份为 1–12
`second`	可选，默认 0
`longitude`	必填，经度范围 −180 到 180；东经为正，西经为负
`latitude`	可选，为记录保留，不参与计算
`utcOffset`	标准时区相对 UTC 的小时偏移，默认 8；夏令时另由 `dst` 处理
`dst`	`"auto"`（默认，UTC+8 时采用中国 1986–1991 年规则）、`true`（强制减 1 小时）、`false`（不做夏令时修正）
`eot`	`"precise"`（默认，按天文位置计算均时差）或 `"simple"`（三项近似公式）

结果中的 trueSolar 是日期时间字段；trueSolarText、meanSolarText 是格式化时间，utc 是对应的 UTC 时刻。dstStatus 标记夏令时状态；dstCorrectionMinutes、longitudeCorrectionMinutes、equationOfTimeMinutes、totalCorrectionMinutes 给出各项修正与总修正。

dstStatus 由 utcOffset 与内置规则判定，不随 dst 的手动开关变化。即使关闭夏令时修正，也可能返回 dst 状态；实际应用的修正应查看 dstCorrectionMinutes。

节气结果包含 index、zh、zhHant、en、longitude、utc 和 beijing。每年从小寒开始，index 为 0–23；beijing 始终为固定 UTC+8，不含夏令时。

让 AI 助手通过 MCP 调用

将以下配置加入支持 stdio 的 MCP 客户端。客户端需要能找到 Git、Node.js 和 npx；首次启动可能需要获取 GitHub 源码、下载依赖并编译。

{
  "mcpServers": {
    "fateclear-solar-time": {
      "command": "npx",
      "args": ["-y", "github:xiaoyu312/fateclear-solar-time"]
    }
  }
}

工具	用途
`true_solar_time`	提供 `datetime`、`longitude` 及可选参数，换算真太阳时
`solar_terms`	提供 `year`，可选 `name`，查询全年或单个节气
`china_dst`	不传参数时返回六年表；提供 `datetime` 时返回状态

datetime 使用 YYYY-MM-DD HH:mm；true_solar_time 也接受 T 分隔和可选秒。各客户端的配置文件位置不同，参数定义见 src/mcp.ts。

使用边界与验证范围

本库做时间换算和历法查询，不生成完整八字排盘，也不作命理判断。
自动夏令时仅内置中国 1986–1991 年规则，并在 utcOffset 为 8 时采用；它不是全球历史时区数据库，也不会根据经度识别国家。其他地区应自行确定标准偏移与夏令时处理。
夏令时状态包括 standard、dst、nonexistent（拨快跳过的时间）和 ambiguous（拨回重复的时间）。自动模式对 dst 和 nonexistent 减 1 小时，对 ambiguous 不减。状态标记不等于消除了歧义，临界时间需由调用者确认。
节气按 astronomy-engine 的太阳视黄经计算。时间格式到秒，不代表绝对误差小于 1 秒；源码测试以 1900–2100 年每 7 年抽样，与 tyme4ts 比较，阈值为 2 分钟，不能外推为所有年份的保证。
simple 均时差是近似值；已有测试对 2000 年每 7 天抽样，与 precise 比较，阈值为 2 分钟。这不是所有日期的误差承诺。
夏令时测试使用 IANA Asia/Shanghai 规则检查各年切换边界。测试定义与 CI 配置可在仓库查看；本次文档整理未重新安装、构建、执行测试或启动 MCP，也未验收在线页面。

已有仓库副本时，可在仓库根目录执行以下开发检查。CI 配置列出 Node.js 18、20、22；此列表不表示本轮已重新验证各环境。

npm ci
npm run typecheck
npm test
npm run build

文档与来源

API 导出 · 太阳时实现 · 节气实现 · 夏令时表
测试覆盖 · 命令和依赖 · CI 配置
配套历法数据：1900–2100 年节气、干支、农历，提供 CSV / JSON；数据采用独立的 CC BY 4.0 许可。

许可与作者

本库采用 MIT。天文算法、MCP SDK、构建及测试依赖的来源与许可见 THIRD_PARTY_NOTICES.md；中国夏令时表来源说明也列于其中。

欢迎体验 FateClear 的生日排盘与解读，或在 X 关注后续项目更新。

Available Tools

3 tools

china_dstB

China daylight saving time 1986–1991: the full table, or the status of one clock time.

Name	Required	Description	Default
`datetime`	No

TDQS

B3.2/5.0

Behavior2/5

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

No annotations are provided, so the description carries the full behavioral burden. It conveys the historical validity window (1986–1991) but says nothing about what happens for out-of-range input, how ambiguous/duplicated clock times during transitions are resolved, or the shape of the returned table/status. For a reference tool with zero annotation coverage this is a significant gap.

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

Conciseness4/5

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

A single dense sentence, front-loaded with the resource and scope, with no filler. It is slightly cryptic ('status of one clock time') but every clause earns its place.

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?

With no output schema and no annotations, the description should explain the return values and error behavior more fully. It covers the two-mode contract adequately but leaves the agent guessing about output format, out-of-range handling, and timezone interpretation.

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% for the single 'datetime' parameter, so the description must compensate. It does partially by implying datetime means 'one clock time' whose DST status is returned, and that omitting it yields the full table, but it gives no format, timezone, or range constraints for the value.

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

Purpose4/5

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

The description states a specific resource and scope ('China daylight saving time 1986–1991') plus the two modes of output (full table vs. status of one clock time). It is clear what the tool returns, but it never differentiates itself from the time-related siblings (true_solar_time, solar_terms), leaving the agent to infer the boundary.

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 phrase 'the full table, or the status of one clock time' implicitly tells the agent when to omit vs. supply datetime, which is genuine routing guidance. However, no explicit when-to-use framing, no exclusions, and no mention of the sibling tools or edge cases (e.g. datetimes outside 1986–1991).

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

solar_termsA

List the exact moments (UTC and Beijing time) of the 24 solar terms for a Gregorian year, or one term if name is given.

Name	Required	Description	Default
`name`	No	e.g. 立春 / Start of Spring
`year`	Yes

TDQS

A3.8/5.0

Behavior3/5

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

No annotations are provided, so the description carries the burden. It does disclose useful behavioral detail — the return values are exact moments in both UTC and Beijing time, and the result set shrinks to one term when name is supplied. However, it says nothing about precision, date-range limits, or error behavior for invalid names, leaving gaps for a no-annotation tool.

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?

A single front-loaded sentence that states the resource, the output time bases, and the parameter-driven branching with no filler.

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?

For a two-parameter read-only lookup with no output schema, the description tells the agent what is returned (UTC and Beijing times) and how name changes the result. Sufficient to call correctly, with only minor gaps around name format and precision.

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 coverage is 50%: name has an example ('立春 / Start of Spring') and year has only type/bounds in the schema. The description adds genuine meaning by tying name to the single-term output mode, but it does not explain accepted name formats beyond the schema example or any year limitations.

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 names a specific verb (List) and a precise resource (the exact moments of the 24 solar terms), plus the scope (Gregorian year) and the narrowing behavior (one term if name is given). This is clearly distinguishable from the astronomy/time siblings true_solar_time and china_dst.

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?

Usage is only implied: pass a year to get all 24 terms, or pass name to get one. There is no explicit when-to-use, when-not-to-use, or mention of the sibling tools, so the agent must infer selection from the single sentence.

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

true_solar_timeB

Convert a clock birth time at a longitude into local true solar time (longitude correction + equation of time, China 1986–1991 DST aware).

Name	Required	Description
`dst`	No
`eot`	No
`datetime`	Yes	Clock time 'YYYY-MM-DD HH:mm' or 'YYYY-MM-DDTHH:mm[:ss]'
`latitude`	No
`longitude`	Yes	East longitude in degrees, west negative
`utcOffset`	No	Clock UTC offset in hours, default 8

TDQS

B3.2/5.0

Behavior3/5

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

With no annotations, the description carries the full behavioral burden and does disclose key computation details: longitude correction, equation of time, and DST awareness for China 1986–1991. However, it does not describe the return format, precision behavior, or error handling, leaving significant gaps for a computation tool with no output schema.

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, front-loaded sentence with no wasted words. The parenthetical efficiently bundles the key technical qualifiers without overwhelming the reader.

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

Completeness2/5

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

For a 6-parameter tool with no annotations, no output schema, and only 50% schema coverage, one sentence is insufficient. It omits return value details, latitude usage, parameter option meanings, and any caveats beyond the China 1986–1991 DST window.

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 only 50%, so the description should compensate for undocumented parameters. It hints at equation of time and DST awareness, which loosely map to the eot and dst parameters, but it never explains latitude, utcOffset defaults, or the enum values for eot and dst.

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

Purpose4/5

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

States a specific verb ('Convert') and resource ('clock birth time at a longitude into local true solar time'), with clarifying scope like longitude correction, equation of time, and China 1986–1991 DST awareness. It is clearly distinct from sibling tools by purpose, though it does not explicitly name solar_terms or china_dst to differentiate.

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

Usage Guidelines2/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 gives no guidance on when to use it versus alternatives such as solar_terms or china_dst. There are no exclusions, prerequisites, or selection conditions to help an agent choose among siblings.

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.

3 tool updatesv0.1.0Oct 20, 2026
- First observedchina_dst
- First observedsolar_terms
- First observedtrue_solar_time

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A3.7/5.0

Scored 2026-10-20 09:50 across 3 tools

Disambiguation5/5

Each tool targets a clearly distinct operation: one converts clock time to true solar time, one lists astronomical solar terms, and one provides China DST data/status. The DST awareness mentioned in true_solar_time does not create ambiguity because china_dst is a standalone lookup tool.

Naming Consistency5/5

All three tools use a consistent snake_case noun-phrase pattern (true_solar_time, solar_terms, china_dst), with no mixing of conventions. The names are descriptive and predictable.

Tool Count5/5

Three tools is a well-scoped set for a specialized solar-time utility. Each tool covers a distinct need without redundancy, fitting the typical 3-15 range.

Completeness4/5

The surface covers core needs: true solar time conversion, solar term moments, and China DST data. A minor gap is the lack of a reverse conversion (true solar time back to clock time) or broader timezone handling, but agents can work around this.

Maintenance

ActivityMaintained

ResponsivenessNo issues

Resources

Related MCP Connectors

小道 Xiaodao A
com.xiaodaox
Bazi (Four Pillars) and Qimen Dunjia charts with true solar time and historical time zones.
Art & Culture
41
https://xiaodaox.com/mcp
D8ly Read A
io.github.dhsiao510
Read-only Bazi, True Solar Time, and Chinese almanac tools in English and Traditional Chinese.
Art & Culture Education & Learning Tools
31
https://d8ly.app/mcp?source=mcp_registry
Chinese Astrology MCP Server by RoxyAPI A
com.roxyapi
BaZi four pillars, Chinese zodiac, lunisolar calendar and almanac days for AI agents.
Art & Culture
161
https://roxyapi.com/mcp/chinese-astrology
Fengshui Calculator A
com.fengshuicalculator
Verifiable Chinese calendar & feng shui: BaZi, flying stars, Kua, almanac. SHA-256 replayable.
Calendar Management
111
https://fengshuicalculator.com/v1/mcp

Related MCP Servers

BaZi (Eight Characters)
Research & Data
minionszyw
F
license
Not graded
quality
Not graded
maintenance
Calculates Chinese BaZi (Four Pillars of Destiny) charts based on birth date, time, and location, including solar term information, decade luck cycles, and true solar time corrections.
Updated a year ago (2025-09-18 08:11 UTC)
2
-
Chinese Fortune Analysis
Research & Data
deeppath-ai
A
license
Not graded
quality
D
maintenance
Enables traditional Chinese fortune-telling through BaZi (Four Pillars) analysis, including solar/lunar date conversion, Five Element balance calculations, Ten Gods deduction, and destiny interpretation for metaphysics applications.
Updated a year ago (2025-09-30 09:45 UTC)
117 npm
MIT
OpenFate Bazi MCPofficial
Art & Culture Research & Data
openfate-ai
A
license
A
quality
A
maintenance
Enables AI agents to calculate deterministic Bazi (Four Pillars) charts with True Solar Time and Earthly Branch interactions, avoiding LLM hallucination of calendrical math.
Updated a month ago (2026-09-20 21:41 UTC)
6
52 npm
160
MIT
Jueshan Paipan MCP
Art & Culture
Riki-1124
A
license
Not graded
quality
C
maintenance
Provides precise Chinese metaphysics chart calculation (Bazi, Ziwei, Qimen) with true solar time correction, outputting structured JSON and Markdown for AI integration.
Updated 3 months ago (2026-08-06 01:17 UTC)
3
MIT

fateclear-solar-time

先看输入与结果

最短接入方式

核心能力

库的用法与参数

让 AI 助手通过 MCP 调用

使用边界与验证范围

文档与来源

许可与作者

Available Tools

TDQS

TDQS

TDQS

Tool Schema Changelog

TDQS

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

BaZi (Eight Characters)

Chinese Fortune Analysis

OpenFate Bazi MCPofficial

Jueshan Paipan MCP