前两天一个做桥梁形变监测的朋友拿着两段相邻时段的观测文件来找我复盘，说跨年那一夜同一个测站算出来的坐标跳了差不多半米，第二天早上又自己跳回去了，问我是不是天线被碰了。我看了眼文件头的时间标签和导航电文里那串 UTC 参数，基本就锁定了原因——不是观测质量问题，是他把 GNSS 时间系统、原子时、协调世界时当成了一个东西在用。这类问题我在授时模块调试、事后精密处理、多系统融合解算这几个场景里见得实在太多了，每次排查到最后，问题都落在"秒"这个最基础的单位上。

GNSS 时间系统这套东西拆开看其实就三件事：原子时负责把"一秒有多长"钉死，协调世界时负责让"现在几点"跟地球自转对得上，而各个卫星导航系统为了让服务连续可用，又各自建了一条不跳秒的专用时标。三者之间差着固定的整数秒、几十纳秒量级的漂移项，以及偶尔冒出来的那一秒闰秒。把这几个量理清楚，转换无非就是几行乘加；理不清楚，误差就会以"整秒"的粒度出现在你最不该出错的地方——时间同步、精密定位、事件打标，一个都跑不掉。下面我把这条链路从设计思路到代码落地完整过一遍，适合刚接触导航数据处理的新手照着抄，也适合做过一段时间但被闰秒坑过的同行对一下账。

1. 为什么不能直接把卫星时间当 UTC 用

1.1 从一次"跳秒"故障说起

先说结论：卫星导航系统对外播发的系统时，绝大多数情况下是一条连续、单调、不跳秒的时间标尺，而协调世界时是一条会因为地球自转变慢而被人为插入或删除整秒的时间标尺。这两条标尺的"秒长"一致，但"时刻"会不定期地错开一秒。你把系统时直接当 UTC 用，平时看不出问题，一旦跨过闰秒生效时刻，所有基于时间的推导都会整体偏移一秒。

一秒听起来不多，但放到具体业务里就很要命。做单向授时的设备，一秒的偏差意味着三百公里的距离误差；做电力同步采样的装置，一秒意味着整周波形的相位彻底错位；做卫星轨道拟合的，一秒的时间标签错误会让观测残差瞬间从厘米级飙到米级。我见过最隐蔽的一次，是某套数据采集程序把接收机输出的 UTC 时间和原始观测时刻混着存，平时两边差 18 秒看不出来（因为都被后续处理统一减掉了），结果闰秒那一晚两边差变成 19 秒，整批数据被判定为粗差全部剔除，排查了整整两天才发现是时间标签的问题。

注意：闰秒不是"每年都有"，它的出现频率完全取决于地球自转的实际情况，可能三五年一次，也可能连续几年都有。任何"写死一个闰秒数"的做法，早晚会出问题。

1.2 四套主流系统的时间标尺差异对照

目前主流的四套全球卫星导航系统，在时间标尺的设计上分成了两个阵营。三套采用"自定义起点 + 周计数 + 周内秒"的结构，秒长与原子时严格一致，全程不跳秒；剩下一套则直接跟随协调世界时的闰秒调整，因此它的时间标尺会出现整秒跳变。这个差异是跨系统数据融合时最容易翻车的地方。

看懂这张表的关键在于分清两件事："秒长"和"起点"。四套系统的秒长都锚定在原子时上，所以它们之间不存在"走得快慢不同"的问题，只存在"起点差多少"的问题。这就好比四块走时同样精准的手表，只是有人把表盘调到了零点，有人调到了别的刻度，你要做的不是校准走时，而是记牢每块表与标准时间的刻度差。

1.3 整条转换链路的设计思路

我在做这类转换时习惯把链路拆成三段，每段只解决一个问题，互不干扰。

第一段是系统时与原子时的对齐，这一段是纯常数，不随时间变化。GPST 与原子时恒差 19 秒，BDT 恒差 33 秒，这些数字从系统设计之初就定死了，永远不会变。把这一段单独拎出来，是因为它最容易记，也最不容易错。

第二段是原子时与协调世界时的对齐，这一段是变量，靠闰秒累积量来维护。截至现在，原子时与协调世界时的差值已经累积到 37 秒。这个数字每次闰秒生效就加一，是整条链路里唯一会"变"的整数部分。

第三段是系统时与协调世界时的精细修正，这一段是纳秒级的小量，靠导航电文里播发的三个参数来补偿。这一段之所以存在，是因为各系统维持的系统时与标准时间之间总有一点微小的频率偏差和相位偏差，需要靠这些参数把它们拉到几十纳秒以内。

三段分开算，出了问题也很好定位：整数秒对不上，查第一段和第二段；纳秒级对不上，查第三段。最怕的就是把三段揉成一个公式，一旦出错连从哪儿查起都不知道。

2. 原子时、世界时与闰秒的三角关系

2.1 原子时为什么必须存在

在原子时出现之前，全世界用的时间基准是天文学测出来的世界时，也就是直接拿地球自转当钟摆。问题在于地球这个钟摆并不稳——自转速度存在长期变慢的趋势，还叠加着季节性的不规则抖动。这就导致"一天"的长度并不恒定，用它来定义"一秒"，秒长就会跟着漂。

原子时的思路很直接：既然天文观测不稳定，那就换一个稳定的物理现象来定义秒。选定某种原子在两个能级之间跃迁时辐射的电磁波频率，把这个频率放大若干倍之后数周期，数够约定的圈数就是一秒。这样定义出来的秒长极其稳定，几十亿年才差一秒。代价是它跟"太阳什么时候升到头顶"这件事彻底脱钩了。

工程上我把原子时理解成一条理想化的、只往前走、永不回头的数轴。它没有时区概念，没有夏令时，没有闰秒，就是一个纯粹的计数量。所有需要高精度计时的场合，最终的溯源目标都是它。

2.2 协调世界时是怎么"缝合"出来的

协调世界时的定位很讨巧：它要秒长跟原子时一样准，时刻跟地球自转一样对。这两个要求本质上是矛盾的，因为地球自转越来越慢，如果一直用原子时的秒长去数，数着数着，"中午十二点太阳在正上方"这件事就会发生偏移。

解决办法就是闰秒。具体做法是：平时协调世界时的秒长完全等于原子时的秒长，两者同步往前走；当监测发现两者的累计偏差快要超过 0.9 秒的时候，就在某个约定的时刻（历史上都选在年中或年末的最后一天最后一秒）把协调世界时"停"一秒或者"跳"一秒。停一秒叫正闰秒，表现为当天最后一分钟有 61 秒，时间从 23:59:59 走到 23:59:60 再走到 00:00:00；跳一秒叫负闰秒，理论上存在，但至今没有实际用过。

这里有个细节值得记住：闰秒只调整协调世界时，不调整原子时。所以每插一次正闰秒，原子时与协调世界时的差值就加一。从 1972 年这套机制正式运行到现在，累计已经加了 27 次，差值从最初的 10 秒涨到了 37 秒。

提示：闰秒的表不是提前很多年就定好的，通常是提前几个月才正式公布。这意味着任何需要长期运行的授时系统，都必须具备"在线接收闰秒更新"的能力，而不能只依赖出厂时烧进去的那张表。

2.3 导航系统为什么要绕开闰秒

看到这里应该能理解，导航系统如果直接跟随协调世界时，会面临一个很尴尬的局面：在闰秒生效的那一刻，系统时间是停住还是跳一下？如果停住，那这一秒内卫星还在飞、信号还在发，时间却不走了，测距计算立刻崩掉；如果跳一下，那接收机在跳变前后的时间标签就对不上，定位结果会出现一次阶跃。

所以三套系统都选择了另起一条不跳秒的时标。这条时标的好处是任意两个时刻的差值都是真实的物理时长，不会因为人为调整而出现"这一分钟有 61 秒"的怪事。做卫星轨道积分、做钟差建模、做多普勒频移计算，用这条时标都是自洽的。

代价就是：系统时和协调世界时之间存在一个缓慢增长的整数偏移。这个偏移不会自己消失，只会随着闰秒的累积越来越大。截至现在，GPST 与 UTC 差了 18 秒，BDT 与 UTC 差了 4 秒。这两个数字不是设计出来的，是"原子时与 UTC 的 37 秒差值"减去"各自与原子时的固定差值"算出来的自然结果。

我在实际项目里踩过一个坑：某次做多系统联合解算，为了省事把四套系统的观测数据统一按 UTC 存了一遍，结果时间标签看着是齐的，实际每套系统的"UTC"含义不同——有的是真 UTC，有的是减了 18 秒的近似 UTC，有的是减了 4 秒的近似 UTC。表面上文件时间戳一致，实际每个观测量的时刻差了十几秒，最后靠对比同一颗卫星在两套系统里的观测时刻，才把这笔糊涂账理清。

3. 核心参数与计算公式拆解

3.1 周数、周内秒与日历时刻的互转

"起点 + 周数 + 周内秒"这个结构看着简单，但它是整条链路的地基，必须掰开揉碎讲。以 GPST 为例，起点定在 1980 年 1 月 6 日零点，从那之后每过 604800 秒算一周，周数加一，周内秒清零重新计数。所以任何一个系统时时刻，都能表示成"第几周 + 这一周内的第几秒"。

说个具体的：算一下 2024 年 5 月 20 日零点的 GPST 周数和周内秒。

第一步，算从起点到这个时刻一共过了多少天。1980-01-06 到 2024-01-06 是 44 年，这期间（含 1980 年，不含 2024 年 2 月之后的闰日）共有 11 个闰年，所以天数是 44 × 365 + 11 = 16071 天。第二步，算 2024-01-06 到 2024-05-20 的天数，1 月剩 25 天、2 月 29 天、3 月 31 天、4 月 30 天、5 月 20 天，合计 135 天。总天数就是 16206 天。

用 16206 除以 7 得 2315 余 1，所以是第 2315 周，周内已经过了 1 天整，周内秒就是 86400 秒。这个结果可以拿来当自检基准：如果你的程序算出来不是 2315 周 86400 秒，那肯定是闰年处理或者起点记错了。

同样的算法用在 BDT 上：起点 2006-01-01，到 2024-05-20 一共过了 6715 天，除以 7 得 959 余 2，所以是第 959 周、周内秒 172800 秒。看出来了吧，同一个物理时刻在两套系统里的表示完全不同，这就是为什么跨系统融合必须显式做转换。

3.2 导航电文里的三个补偿参数

整数秒的部分靠闰秒累积量解决，但那只精确到整秒。要拿到几十纳秒级的精度，还得靠导航电文里播发的一组参数。这组参数核心有三个：

• A0：协调世界时偏移的常数项，单位是秒，量级通常在几十到几百纳秒之间。
• A1：协调世界时偏移的漂移率，单位是秒每秒，量级通常在 1e-15 到 1e-14 之间，对应的就是每天几十纳秒的漂移。
• Tot：上述参数的参考时刻，用电文所在周的周内秒表示。

配套还有两个跟闰秒直接相关的字段：当前闰秒累积量和下一次闰秒累积量，前者是当前生效的整秒数，后者是即将生效的整秒数，二者不等就说明有闰秒预告还没到生效时刻。此外还有一个闰秒生效周数和一个日序号，用来精确定位闰秒发生在哪一天。

完整的换算公式是这样：

Δt_UTC = Δt_LS + A0 + A1 × (tE − Tot) t_UTC = tE − Δt_UTC

其中 tE 是用户推算出的系统时，Δt_LS 是当前闰秒累积量。这里有个必须处理的边界：tE 和 Tot 可能不在同一周。如果两者相减的结果大于 302400 秒，就要减掉一个整周 604800 秒；如果小于 −302400 秒，就要加上一个整周。这个 302400 就是半周，本质上是"就近取周"的处理逻辑，不做这一步，跨周的参数计算会凭空多出或者少掉一周的漂移量。

3.3 闰秒参数的一个实际取值示例

拿 2017 年元旦那次闰秒举例。这次闰秒生效后，GPST 与 UTC 的差值从 17 秒变成 18 秒，原子时与 UTC 的差值从 36 秒变成 37 秒。对应到电文参数上，闰秒生效周数记录的是"第 1929 周的周日"，日序号是 7（周日）。由于这个周数字段是 8 位表示，实际存进去的是 1929 对 256 取模的结果 137。

这一次闰秒的生效时刻，用 UTC 表示是 2016 年 12 月 31 日的 23:59:60，用 GPST 表示则是 2017 年 1 月 1 日的 00:00:17。两者的对应关系可以这样验算：闰秒生效之前，累加量是 17 秒，所以 UTC 的 23:59:59 对应 GPST 的 00:00:16；跳进闰秒那一秒，UTC 走到 23:59:60，GPST 走到 00:00:17；闰秒结束后 UTC 走到 00:00:00，GPST 走到 00:00:18。整条曲线在 GPST 上是连续均匀的，在 UTC 上则多插了一格。

注意：这意味着一张按 GPST 连续采样的观测表，如果转成 UTC 显示，会在闰秒那一刻出现一个重复或者空白的秒值。两个 GPST 时刻可能对应到同一个 UTC 秒（正闰秒时 UTC 的 23:59:60 只对应 GPST 的一个秒，但 UTC 的 23:59:59 和 00:00:00 之间的间隔变成两秒），处理时序数据时如果按 UTC 排序去重，很容易丢数据。

4. 实操：从解析到代码的全流程落地

4.1 数据准备与解析入口

动手之前先确认手里有什么。常见的数据来源有三类：接收机实时输出的语句、观测数据文件、广播星历文件。这三类的时间标签含义并不相同，混淆了就是灾难的开始。

接收机输出的时间语句，默认给的一般是协调世界时，但不同厂商、不同配置下可能输出的是系统时，这个必须查手册确认。观测数据文件的时间标签，在常见的格式约定里一律用 GPST 表示，跟闰秒无关，所以跨闰秒的观测文件在时间上是连续的。广播星历文件里既有系统时表示的参考时刻，也有用于换算到协调世界时的补偿参数，两套东西并存。

解析观测文件时重点看文件头的首历元时间行，格式大致是年、月、日、时、分、秒、时间系统标识七个字段，最后的标识会明确写出这是哪套时标。这一步千万别跳过，有些处理软件默认按协调世界时读，遇到标注为系统时的文件就会整体偏移。

4.2 用代码把整条链路串起来

理论讲完，直接上代码。下面这段用 Python 写的转换模块，把前面说的三段逻辑都实现了，可以直接拿去改。

from datetime import datetime, timedelta, timezone from bisect import bisect_right UTC = timezone.utc # 系统时起点 GPST_EPOCH = datetime(1980, 1, 6, tzinfo=UTC) BDT_EPOCH = datetime(2006, 1, 1, tzinfo=UTC) # 系统时与原子时的固定差（秒），永不变化 GPST_TAI_OFFSET = 19 BDT_TAI_OFFSET = 33 SEC_PER_WEEK = 604800 # 闰秒表：(生效的 UTC 时刻, 生效后的累积量) LEAP_TABLE = [ (datetime(2006, 1, 1, tzinfo=UTC), 33), (datetime(2009, 1, 1, tzinfo=UTC), 34), (datetime(2012, 7, 1, tzinfo=UTC), 35), (datetime(2015, 7, 1, tzinfo=UTC), 36), (datetime(2017, 1, 1, tzinfo=UTC), 37), ] _LEAP_KEYS = [x[0] for x in LEAP_TABLE] def leap_seconds_at(dt_utc: datetime) -> int: """查某个 UTC 时刻对应的原子时-UTC 累积差""" idx = bisect_right(_LEAP_KEYS, dt_utc) - 1 if idx < 0: return 10 # 1972 年机制启用时的初值 return LEAP_TABLE[idx][1]

上面这段是基础数据。真正做转换的时候，方向不同，遇到的坑也不同：从系统时转协调世界时，因为累加量是"待求"的，需要迭代；从协调世界时转系统时，累加量可以直接查表，一步到位。

def utc_to_gpst(dt_utc: datetime) -> datetime: """协调世界时 -> 系统时（GPST）""" ls = leap_seconds_at(dt_utc) return dt_utc + timedelta(seconds=ls + GPST_TAI_OFFSET) def gpst_to_utc(dt_gpst: datetime, max_iter: int = 4): """系统时（GPST） -> 协调世界时，迭代收敛处理闰秒边界""" ls = 18 # 合理初值，加速收敛 candidate = dt_gpst - timedelta(seconds=ls + GPST_TAI_OFFSET) for _ in range(max_iter): new_ls = leap_seconds_at(candidate) if new_ls == ls: break ls = new_ls candidate = dt_gpst - timedelta(seconds=ls + GPST_TAI_OFFSET) return candidate, ls def dt_to_week_tow(dt: datetime, epoch: datetime): """日历时刻 -> (周数, 周内秒)""" if dt.tzinfo is None: raise ValueError("必须显式指定时区，否则必错") total = (dt - epoch).total_seconds() week = int(total // SEC_PER_WEEK) tow = total - week * SEC_PER_WEEK return week, tow def week_tow_to_dt(week: int, tow: float, epoch: datetime) -> datetime: """(周数, 周内秒) -> 日历时刻""" return epoch + timedelta(weeks=week, seconds=tow)

这段代码里最关键的一行是gpst_to_utc里的迭代。为什么必须迭代？因为你要减去多少秒，取决于结果是落在闰秒生效之前还是之后，而结果又取决于减去多少秒——典型的循环依赖。迭代三到四次一定收敛，实测下来绝大多数情况两次就稳了。

4.3 加上补偿参数的完整版

前面那段只处理了整数秒，要做到纳秒级还得把播发参数带进来。

def apply_utc_correction(t_sys: float, tow_ref: float, a0: float, a1: float, dt_ls: int) -> float: """ t_sys : 用户推算的系统时（周内秒） tow_ref : 参数参考时刻（周内秒） a0, a1 : 播发的补偿参数 dt_ls : 当前闰秒累积量 返回 : 系统时相对协调世界时的总偏移（秒） """ dt = t_sys - tow_ref # 就近取周，处理跨周 if dt > 302400: dt -= SEC_PER_WEEK elif dt < -302400: dt += SEC_PER_WEEK return dt_ls + a0 + a1 * dt

实测一组典型参数：A0 取 -1.86e-9 秒，A1 取 -8.88e-16，参考时刻取某一周的 589824 秒。假设用户在 600000 秒处求值，代入后漂移项的贡献是 -8.88e-16 × (600000 − 589824) ≈ -9.0e-12 秒，也就是负 9 皮秒，比常数项小三个数量级。所以对于大多数厘米级、分米级应用，漂移项可以忽略，但做授时和精密定轨就必须带上，因为累计下来一天也能到几十纳秒，对应厘米级的距离变化。

提示：这套补偿参数描述的是"系统时与协调世界时的偏差"，跟卫星钟差参数完全是两码事。卫星钟差描述的是"卫星钟与系统时的偏差"，作用对象不同，别往一个公式里塞。

4.4 自检环节必须做三件事

代码写完别急着跑生产数据，先过三道自检。

第一道，用已知的闰秒时刻做回归。取 2017 年元旦那次闰秒，验证你的函数能否正确给出闰秒前后的 17 秒和 18 秒，以及对应的系统时是否正确。这道过了，整数秒的部分基本就稳了。

第二道，用长跨度做连续性检查。取一个跨越多年的时刻序列，转成系统时再转回来，看往返误差是不是严格为零。如果出现累积漂移，多半是浮点精度或者闰年处理出了问题。

第三道，用负数和边界值做鲁棒性检查。比如把时刻设在闰秒生效前一毫秒、后一毫秒、正好一秒，看函数表现是否一致，有没有抛异常或者返回 None。

我自己的习惯是把这三道检查写成单元测试固定下来，每次改动转换逻辑就跑一遍。这套测试帮我挡过至少两次回归——有一次改了个"优化"的分支判断，看着无害，结果把闰秒前一秒的判断条件写反了，正好被测试拦住。

5. 多系统融合场景下的影响范围

5.1 融合解算该选哪个时标当基准

做单系统解算时，时标选择其实无所谓，因为所有观测量都在同一套标尺上，最后的钟差参数会自动吸收掉那个常数偏移。一旦上多系统融合，问题就来了：不同系统的观测量带着不同的时间标签，如果不在解算前统一，等价于给每个系统额外加了一个未知的钟差，这个钟差跟接收机钟差会互相纠缠，解算器要么发散，要么收敛到一个错误的解。

我的做法是统一到一条连续的系统时标上，通常选观测数据量最大的那套系统的时标作为基准，把其他系统的观测量先转换过来。选连续时标而不是协调世界时，理由是连续性有保证，不会在解算过程中因为闰秒突然出现一秒的跳变，把滤波器的状态搅乱。

转换的时候要注意，不同系统之间的换算不是简单加减一个整数。因为各系统与原子时的固定差值不同，两两之间的差值也要先算清楚。比如 GPST 与 BDT 之间的差值就是 33 减 19 等于 14 秒，跟闰秒没有任何关系，是个纯常数。这个常数可以直接写死在配置里，不需要动态查询。

5.2 授时与时间同步业务的特殊处理

做授时业务的同行对这件事的敏感度最高。设备对外输出的一般是协调世界时，内部处理的却是系统时，中间这条转换链路的任何一处偏差，都会直接体现在输出精度上。

这里有个容易忽略的点：闰秒预告必须提前处理。因为闰秒生效后，累积量才加一，但设备在生效前就已经需要知道"再过多久会跳"。如果设备只认当前累积量，那它在闰秒生效的那一刻会突然发现自己的输出跳了一秒，如果下游设备没准备好，就会触发保护或者失步。正确的做法是把"当前累积量"和"下一次累积量"都读进来，在生效时刻到来前平滑切换，或者至少提前发出告警。

还有个更细的坑：某些设备在闰秒那一秒的处理上，会输出 23:59:60 这个"非法"时间值，而下游的解析程序用标准时间库解析时直接抛异常。这个问题我在三个不同项目里都遇到过，解决办法无非两种——要么在解析层做特殊判断，把 60 秒单独识别出来映射到系统时的对应秒；要么在输出层就禁止出现 60 秒，统一按系统时输出，让用户自己转。两种方案各有取舍，但一定要在接口文档里写清楚，别让对接方猜。

5.3 事后精密处理中的时间标签

事后处理对时间精度的要求比实时高一个量级，因为要做精密定轨和坐标解算，时间标签错一毫秒，卫星位置就错好几米。这个场景下时间标签的处理有两个要点。

一是确认数据文件的时间系统标识，别想当然。虽然主流格式约定用系统时，但总有些特殊产品用别的标尺，文件头里写了就得按写的来。我见过一次，某批数据文件头里明明白白标着系统时，但实际内容是协调世界时，原因是生成这批文件的程序在写入时用错了变量。这种问题只能靠交叉验证发现——拿同一时段的广播星历算卫星位置，跟精密星历比对，残差出现整秒级别的系统性偏移，基本就能定位。

二是跨闰秒的数据段要单独标记。做长弧段拟合时，如果数据跨了闰秒，时间标签在协调世界时维度上是不均匀的，直接按等间隔假设去拟合会引入系统性误差。稳妥的做法是在数据处理流程里加一道检查，识别出跨闰秒的时段，在该处断开弧段或者显式建模这一秒的跳变。

6. 踩坑实录与排查速查表

6.1 常见问题速查

下面这张表是我这些年攒下来的，基本都是实际排查过的案例，按现象倒查原因，能省不少时间。

6.2 周数回绕这个坑值得单独说

系统的周数字段位宽是有限的，10 位字段最大只能表示到 1023 周，超过就回绕到 0。以 GPST 为例，从 1980 年起点算起，第一次回绕发生在 1999 年 8 月下旬，第二次发生在 2019 年 4 月上旬。每次回绕，接收机如果没做处理，就会把时间算回二十年前。

这个坑的隐蔽之处在于：回绕不是故障，是设计如此。设备在回绕当天工作完全正常，只是日期算错了。做数据归档的系统如果只存周数不存完整日期，回绕之后就会出现大量"时间倒流"的记录。

处理办法有两个层面。硬件层面，现代接收机基本都做了扩展处理，输出完整周数；软件层面，无论硬件是否处理，解析程序都应该加一道合理性检查——如果算出来的日期跟系统当前时间差了接近 20 年，基本可以断定是回绕问题，按 1024 周的整数倍补回去就行。这个检查成本极低，但能挡住一类非常难查的故障。

6.3 几条只有踩过才记牢的经验

第一条，永远不要相信"这个值不会变"。闰秒累积量会变，补偿参数会变，甚至系统时与协调世界时的差值在未来也可能因为机制调整而停止增长。所有跟时间相关的常数，都应该做成可配置项，而不是硬编码在代码里。我见过一个项目把 18 秒写死在三个不同的文件里，后来闰秒更新时只改了两个，第三个成了定时炸弹。

第二条，记录原始时标，别急着转换。数据落盘的时候，最稳妥的做法是把原始时间标签和时标标识一起存下来，转换放到使用环节做。这样即使转换逻辑出了 bug，原始数据还在，改完重新跑一遍就行。反过来，如果落盘时就转了，一旦转错，原始信息就永久丢失了。

第三条，用真实数据验证，别只用构造数据。构造数据能测出逻辑错误，但测不出边界情况。我强烈建议找一批跨过闰秒的真实观测数据跑一遍，看看解算残差在闰秒前后有没有跳变。真实的接收机在闰秒前后的行为千奇百怪，有的会短暂失锁，有的会输出重复时间戳，这些在构造数据里都模拟不出来。

最后再分享一个我自己的小习惯：每次遇到时间相关的诡异问题，先不急着看代码，而是拿一张纸把"这个数据从产生到使用，中间经过了几次时间标签的读写"这条链画出来，每一环标注它用的是哪套时标。画完这张图，问题往往自己就浮出来了。我排查过的时间类故障里，八成以上不是公式写错，而是某一环的时标归属搞混了——公式从来没错，错的是喂进去的那个数根本就不是你以为的那套时间。