Gpsd 错误可能会在 10 月 23 日造成 1024 周的时间扭曲

我刚刚在所有分支的 timebase.c 模块中发现了一个潜伏的问题 >=3.20: /* sanity check week number, GPS epoch, against leap seconds * 不适用于回归，因为leap_sconds * 可能来自接收器，或来自 BUILD_LEAPSECONDS。 */ if (0 < session->context->leap_seconds &&

19 > session->context->leap_seconds && 2180 < week) { /* 假设闰秒 = 19 到 2022 年 12 月 31 日 * 所以周 > 2180 是未来的方式，不允许 */ 周 -= 1024; GPSD_LOG(LOG_WARN, &session->context->errout, "GPS 周混乱。调整周 %u 以实现跳跃 %d\n",

周，会话->上下文->leap_seconds);这段代码将触发从 2021 年 10 月 16 日星期六到 2002 年 3 月 3 日星期日的 1024 周向后时间跳跃。 /* 针对闰秒的健全性检查 unix 时间。

* 不适用于回归，因为leap_sconds * 可能来自接收器，或来自BUILD_LEAPSECONDS。 * 2017 年 1 月 1 日闰秒 18：1483228800 *（long long）对于 32 位系统 */ if (17 < session->context->leap_seconds && 1483228800LL > t.tv_sec) { long long old_tv_sec = t.tv_sec;

t.tv_sec += 619315200LL； // 快进 1024 周 (void)gmtime_r(&t.tv_sec, &session->nmea.date); // 修正 NMEA 日期 (void)timespec_to_iso8601(t, scr, sizeof(scr)); GPSD_LOG(LOG_WARN, &session->context->errout, "警告: WKRO 错误: 闰秒 %d 与 %lld 不一致, 更正为 %lld (%s)\n", session->context->leap_seconds,

old_tv_sec, (long long)t.tv_sec, scr); }