OPC UA DateTime 的 100ns 从 1601 算起，Python 微秒怎样保留余数

UA DateTime的Int64计数从1601年1月1日UTC开始，单位100纳秒。Python datetime只到微秒，应使用整数divmod保留除以10后的余数，不能先转浮点秒；零和极值时间还需要作为无效边界单独处理。

适用版本与输入范围

依据 OPC Foundation 官方参考，v105 链接在核对时显示 v1.05.07，具体 Part 与章节见文末。示例只处理明确声明的值与结构，不实现网络会话、证书或完整服务端。 本文所有输入均为原创合成数据，未接真实设备。

纪元与单位必须同时确认

附件116444736000000000恰好对应1970年1月1日UTC，2026年10月24日则是134372736000000000。若把这个大整数按Unix毫秒或纳秒解释，日期会落到完全不同范围，不能靠界面显示“像一个时间”判断正确。线上二进制值应先按小端有符号Int64取数，本附件直接保存整数计数，重点验证纪元与精度转换，不再混入字节提取步骤。

用整数拆分微秒和剩余百纳秒

程序对ticks执行divmod(ticks,10)，商作为相对1601纪元的微秒，余数0到9独立保存。第二条正例比Unix纪元多七个100纳秒，Python可显示部分仍是00:00:00.000000，但remainder_100ns=7，证明没有偷偷四舍五入。不能把完整ticks转为float再除一千万，大整数会在转换前先丢低位；一旦丢失，随后增加显示位数也无法恢复。

最小极值不是正常采样时间

零编码是最小边界，不应在业务曲线里画成1601年正常点。规范对平台可表示范围的边界有特殊映射，本程序以minimum_sentinel和maximum_sentinel保留不可用状态，且拒绝超出Int64的输入。对于正计数但超出Python日历范围的情况，明确报错，不静默夹到某个当前年份。日期能表示不等于数据有效，使用时仍需结合DataValue中的StatusCode与字段是否出现。

精度保留不等于现场准确度

保留七个百纳秒余数只是数学表示能力，不能宣称服务器时钟准确到700纳秒，更不能推导网络传输时延。采样时钟、来源与同步状态必须由实际系统提供证据。报告UTC字符串与余数应一起存储，若下游只支持微秒，需显式声明截断策略；不能把丢掉余数的文本又称为原始无损时间。本次程序没有访问服务器或本机对时配置，输出均为合成计数的确定性转换。

下载与复跑

将输入 fixture.json与独立程序 verify.py放在同一目录，用 Python 3.12 执行 python verify.py，无需安装第三方包。程序从自身目录读取输入并写入 report.json，不要求当前终端恰好位于下载目录。也可查看本次实跑报告和复跑说明。

本次实际运行通过 5 条输入断言，包括标有“显式负例”的记录；负例以JSON字段承载，不会把下载文件本身做成损坏编码。utc只含Python微秒精度，remainder_100ns保留低位；sentinel状态不生成正常采样日期。 修改输入后应同时审查期望结果，不能只改断言数字让测试变绿。

对象或字段的基础关系可回到楼宇与工业数据接入链路核对，更多接口入口在设备协议库。若需要把已确认的数据点接入展项编排，可了解SoftControl 展厅中控；具体接入能力以项目确认和实际测试为准。

一级依据

• DateTime signed Int64 and truncation

来源核对日期：2026-10-24。离线结果只证明给定输入的解析或计算行为；现场兼容性、响应时间、硬件准确度和具体产品支持均未测量。