 wandering1
|
0ae9c10f24
|
docs(时间): 时基口径定稿——内部一律本地钟面（用户裁定「时基先本地为准」），并纠正本文自相矛盾
用户裁定原文：「**时基先本地为准**」。这条定的是**冲突时谁赢**：面板时钟页与 8888 对时把「本地钟面当
epoch」写入，而 104 的 `C_CS NA` 对时命令携的是 UTC，两条写入口**后写者赢** ⇒ 装置墙钟与主机本地时刻
恒差 8 小时。裁定结束「后写者赢」：**内部真源 = 本地钟面**，任何来源写入前都先换算成本地钟面再落库。
**顺手挖出这条 8 小时的真正根因：本文自己就是矛盾的**——§2 的术语表把 epoch 定义成「自 1970-01-01
00:00:00 **UTC** 起的秒数」，而 §15 网络校时协议字段写的是「**本地** Unix 时间戳，与电脑显示一致」；代码
按后者实现。所以「恒差 8 小时」不只是两条写入口打架，**规范文本也没统一过**。现在 §2 改成「本地时间戳：
把本地钟面按 UTC 记法数出来的秒数，内部不加任何时区偏移」，§13 那行旧建议「如需 UTC/时区可在 API 层
加偏移参数」一并标作废（它会把「装置不存时区」这个优点拆掉）。
**为什么选本地**：日志时标、UI 显示、FAT 文件时间三者都是**给现场电气工程师读的**，跟装置所在地钟面
一致才没有解释成本；装置不存时区、不做夏令时，也就没有「时区参数配错」这一类故障。
⚠ **本笔刻意不做的一件事，也是本笔唯一需要人看的地方**：104 **上行**时标 `CP56Time2a` 按标准应发 UTC，
而 `iec104_epoch_ms_to_cp56()` 现在是把内部值**直接按 UTC 分解**发出——即发出去的是本地钟面值。两条出路
要么给装置一个时区常量并上行前减偏移（标准符合，但与「不存时区」相冲），要么维持发本地值（同时区现场
看着正确，第三方主站按 UTC 解读会差 8 小时）。**这不是 bug 修复，是产品对外语义决定，牵动送检与第三方
主站验收**，所以本轮**一行代码都不改**，只把分岔与后果写进 §1.1 末，等单独裁定。
自查：`check_doc_links --all` exit 0（198 篇）、本篇 `--sections-strict` 通过、noBOM
/ LF / U+FFFD=0 / 结尾
换行齐、不可判定绝对数 979 未变；本笔**纯文档**，零代码零编号。此刻另有五条道在飞（通讯页 / 计数器 /
对时留痕 / 台架判据文档 / 记录页设计），故只提交这一只文件，其余按道分笔。
|
2026-10-27 10:50:16 +08:00 |
|