FieldPoint 时间戳转字符串差 1 小时-平芜编程栈

在 FieldPoint 控制器上把时间戳转成字符串，同一个时间戳、同一个格式串，只因为 "UTC format?" 输入给的是 True 还是 False，两个显示控件就给出相差一小时、日期也不同的结果。控制器时区本就设为 UTC，DST 补偿也是关闭的，两条路径按理应当一致。

左：utc_time.vi 的框图，同一个时间戳经 Format Date/Time String 转换，UTC format? 分别接 True 与 False，输出到两个显示控件；右：前面板结果，Time Now (UTC) 为 16 Jun 2009 23:17:42，Time Now (UTC) 2 为 17 Jun 2009 00:17:42

01 现象

一个把时间戳转成字符串的 VI，输入同一个时间戳、同一个格式串 "%d %b %Y %H:%M:%S"，只把 "UTC format?" 这个布尔输入分别接 True 和 False，两个显示控件的结果就不一样：接 True 的显示 16 Jun 2009 23:17:42，接 False 的显示 17 Jun 2009 00:17:42。两者正好差一小时，而且跨过了零点，日期也跟着差一天。

运行环境是 FieldPoint 控制器，控制器时区设为 UTC，DST 补偿关闭，RT 版本为 8.5.1。正因为时区是 UTC、又不做夏令时补偿，True 和 False 本应给出同一个结果。

值得注意的是：MAX 里读到的数据时间戳本身是正确的，用 "UTC format?" 接 True 得到的字符串也是正确的。也就是说正确值一直都在，出错的只有 False 这一条路径。

02 根因

这是 FieldPoint 控制器上的一处已知问题。官方复现之后确认研发侧已经知晓，并且给出了明确的范围边界：受影响的是 PharLap 架构的 FieldPoint，VxWorks 架构的 FieldPoint 不受影响。

成因不在调用方。同一个时间戳、同一个格式串，差的只是一个布尔端子，所以问题出在 False 这条转换路径对时间的处理上，与传入的时间戳格式无关，也与前面的数据采集无关。"UTC format?" 这个端子决定的是转换时把输入当作 UTC 还是当作本地时间去解释，而控制器时区本来就是 UTC、DST 补偿也是关闭的，两条路径的基准本该重合。既然结果是 True 对、False 错，那偏差就只能来自 False 这条路径对时区偏移的处理，而不是来自输入数据。

这个现象能在多个版本上复现，从 RT 6.1 到 8.5.1、8.6.1 都有报告，可见它不是某一版的偶发回归，而是这条路径上一段稳定存在的旧逻辑。后续信息显示，它对应的问题编号为 CAR 41190，并已修复，只是当时没有给出具体的修复版本号。也就是说，在拿到对应的修复版本之前，能依靠的只有绕开这条分支。

03 怎么做

最直接的做法是把 True 接到 "UTC format?" 端子上。既然 False 这条路径算错、True 这条路径算对，而现场的需求恰恰就是 UTC 时间字符串，那么直接绕开有问题的分支即可，不必等版本升级。

如果确实需要在 False 分支上继续用（比如字符串里要带本地时间语义），就要留意：在拿到修复版本之前的 PharLap FieldPoint 上，这条路出来的时间不可信，不能拿它去对齐数据。稳妥的办法是在程序里统一走 True，把时区换算放到明确的地方去做，而不是依赖这个端子的默认行为。

上机核对时，可以让两条路径在同一时刻各输出一次，再拿 MAX 里读到的数据时间戳作基准去比：True 分支与 MAX 一致，False 分支偏离，就说明命中的是这里的已知问题，而不是程序里格式串写错或者数据源本身带了错误的时区。

排查时还要分清平台。后来出现过在 LabVIEW 2012 上观察到类似偏差的报告，但经核实那是 LabVIEW 在本地时间与 UTC 转换上的另一个问题，出现在 BST 期间，与这里的 FieldPoint 问题不是同一回事。所以遇到"时间差一小时、差一天"这类现象，先确认代码是跑在 RT 目标上还是 Windows 上，再决定往哪个方向查。平台不同，责任方和修法都不同，混在一起排查只会绕远路。