时间 · XB 现场笔记

PostgreSQL 时间函数取样于不同的时点

Thu, 13 Jan 2028 00:00:00 +0000

PostgreSQL 提供多种“当前时间”。事务时间标记事务开始，语句时间标记客户端命令到达，墙钟读数则在表达式求值时读取当前时钟。选择不同函数，会改变审计字段、过期检查和长任务中间观测的含义。应先明确要记录哪个事件，再决定函数，不能因为名称都有时间含义就随意互换。

一个事务只有一个开始时刻

now()、transaction_timestamp() 与不带精度参数的 CURRENT_TIMESTAMP，返回同一个事务开始瞬间。在显式事务里，它们始终固定，即使后续语句已经晚了几秒或几分钟。CURRENT_TIMESTAMP 可以指定精度来舍入结果；小数位数的处理与采样时刻是两回事，不能因为显示精度不同就推断时钟来源改变。

这种稳定性适合让相关行共享同一个逻辑事务时间。它不记录每行真正插入的时刻，也不是最终提交时间。事务可能先等待锁或执行大量计算，随后才插入数据，最后还有可能回滚。把列命名为 created_at，并不能自动说明默认值到底代表哪个事件，需要在数据契约里写清楚。

普通自动提交模式下，连续语句通常各自处于不同事务，因此 now 看起来会随每条语句前进。但这种观察没有改变函数契约。后来为了原子性加上显式事务时，原本被误认为实时变化的时间，就可能暴露出早已固定的问题；验证时应覆盖真实事务边界，而不只在交互终端连续敲两条查询。

语句标记与实时读数

statement_timestamp() 返回服务器收到最近一条客户端命令消息的时间，在该命令执行期间保持稳定。事务中后续命令的语句时间可能与事务时间不同。同一协议消息里发送的多条 SQL 命令，也可能共享这个标记，所以它不一定代表等待结束后，每个内部操作真正开始的那一刻。

clock_timestamp() 在求值时读取当前墙钟，即使同一条语句内部也可能变化。由于时钟精度有限，两次调用并不保证得到不同值。它也不是单调计时器，时钟校正可能影响前后读数的差值。需要保证耗时测量不受墙钟调整影响时，应使用合适的单调时钟，而不是把数据库墙钟当成无条件递增的计数器。

这些值单独使用，都不能证明并发事务的提交顺序，也不能提供唯一事件身份。相关字段需要一致逻辑时间时选事务标记，观测命令到达时选语句标记，需要读取当前墙钟时才选实时观测。身份与顺序要求应另外明确，不能让时间戳自动承担它未承诺的语义。

坏掉的样子

长事务中的过期检查如果使用 now，就会持续与事务开始时刻比较。一个在事务开始时成立的条件，即使真实墙钟已经越过截止时间，也可能继续成立。即便使用 clock_timestamp，也只检查求值瞬间，不能保证稍后的提交仍在截止时间之前。要求提交时有效的业务规则，需要另外设计并发与时间边界。反过来，把全部默认值换成 clock_timestamp，又可能让本该共享逻辑创建时间的相关行各不相同。修改函数前，应先确定列代表的是业务批次、命令到达还是实际观测。

列默认值中的特殊字面量 TIMESTAMPTZ 'now' 也是一个陷阱。PostgreSQL 在解析常量时就把它转换成时间，所以后续插入可能一直拿到建表时刻。DEFAULT now() 是函数调用，会在真正使用默认值时求值。两种写法看起来相似，并不代表求值生命周期相同；只检查默认表达式包含 now 这个词，会漏掉这个差别。

这些函数返回 timestamptz。切换会话时区会改变瞬间的显示形式，而不是改变已存储的瞬间本身。timestamptz 不保留最初传入的时区名称；应用需要记住原始时区时，应单独建模，不能从后来显示的偏移量反推原始地区。相同偏移量也不足以唯一确定某个时区名称。

快速验证

把下面内容保存为 timestamps.sql，在可丢弃的 PostgreSQL 18 数据库中执行 psql -X -v ON_ERROR_STOP=1 -f timestamps.sql。显式事务之外，应保持 psql 默认的自动提交行为；第二段需要让两次插入分别处在不同事务里。所有表都是临时表。

\set ON_ERROR_STOP on
BEGIN;
SET LOCAL timezone='UTC';
CREATE TEMP TABLE moments (step integer,tx timestamptz,statement timestamptz,wall timestamptz);
INSERT INTO moments VALUES (1,now(),statement_timestamp(),clock_timestamp());
SELECT pg_sleep(0.03);
INSERT INTO moments VALUES (2,CURRENT_TIMESTAMP,statement_timestamp(),clock_timestamp());
SELECT step,tx,statement,wall FROM moments ORDER BY step;
SELECT min(tx)=max(tx) AS one_transaction_time,
 count(DISTINCT statement)=2 AS two_statement_times FROM moments;
SELECT now()=transaction_timestamp() AND now()=CURRENT_TIMESTAMP AS aliases;
SELECT extract(epoch FROM now()) AS instant_utc;
SET LOCAL timezone='Asia/Shanghai';
SELECT now() AS same_instant_different_display,extract(epoch FROM now()) AS instant_shanghai;
DO $$ BEGIN
 IF (SELECT min(tx)=max(tx) FROM moments) IS DISTINCT FROM true THEN
 RAISE EXCEPTION 'transaction time changed';
 END IF;
 IF now() IS DISTINCT FROM transaction_timestamp() THEN RAISE EXCEPTION 'aliases differ'; END IF;
 IF (SELECT tx FROM moments WHERE step=1) IS DISTINCT FROM now() THEN
 RAISE EXCEPTION 'time zone changed the instant';
 END IF;
END $$;
ROLLBACK;
CREATE TEMP TABLE defaults_demo (
 id integer,
 parsed timestamptz DEFAULT TIMESTAMPTZ 'now',
 called timestamptz DEFAULT now()
);
INSERT INTO defaults_demo (id) VALUES (1);
SELECT pg_sleep(0.03);
INSERT INTO defaults_demo (id) VALUES (2);
SELECT id,parsed,called FROM defaults_demo ORDER BY id;
SELECT min(parsed)=max(parsed) AS one_parsed_constant,
 count(DISTINCT called)=2 AS two_insert_transaction_times FROM defaults_demo;
DO $$ BEGIN
 IF (SELECT min(parsed)=max(parsed) FROM defaults_demo) IS DISTINCT FROM true THEN
 RAISE EXCEPTION 'parsed default was evaluated again';
 END IF;
END $$;
DROP TABLE defaults_demo;

本轮 PostgreSQL 18.6 单用户重跑将命令分别输入，前两行共享相同 tx，但 statement 和 wall 读数不同；未测试 psql 客户端协议。别名比较返回真。从 UTC 切换到 Asia/Shanghai 后，显示偏移变成东八区，但两次 epoch 值完全一致。断言检查事务时间稳定，并确认时区切换没有改变同一个瞬间，而不是仅凭显示字符串判断。

回滚第一段后，默认值实验在两个独立事务中分别插入一行。两行 parsed 保留相同的解析期常量，而 called 随插入事务变化。短暂休眠是为了让本次差别容易观察，并不保证时钟分辨率或调度延迟。最后的 DROP 清除第二张临时表；如果断言提前终止，连接结束也会清理临时对象，实验不会留下持久业务数据。

来源

PostgreSQL 日期时间函数，事务、语句、墙钟和默认值求值语义，已核验 2026-10-15。
PostgreSQL 日期时间类型，timestamptz 存储、显示和特殊输入字面量，已核验 2026-10-15。

分别检查 timesyncd 服务状态与时钟证据

Thu, 11 Mar 2027 00:00:00 +0000

systemd-timesyncd 是一个精简 SNTP 客户端，用配置的时间源同步本地系统时钟。它可以帮助证书检查与墙钟时间戳保持有意义，但不会无条件保证某个精度范围。守护进程能否运行、是否收到可接受样本，以及系统是否报告同步，是需要分别确认的事实。只看到安装了客户端，或者某条命令成功返回，都不足以推导时钟已经准确。

坏掉的样子

守护进程并不总是平滑校正。文档明确说明，大偏差会直接跳时，小偏差则逐渐调整。因此，开机时离正确时间很远的机器，可能发生时间不连续。经过时长测量应使用单调时钟，解释墙钟时间戳的应用则应处理校时，而不是假定时间永远平滑前进。不能把“精简客户端”误写成“绝不会让应用看见时间跳跃”。

FallbackNTP 不是显式服务器不可达时就一定会启用的通用应急列表，它在没有其他已知服务器信息时才适用。全局 NTP 条目和 networkd 提供的链路时间源，优先于这个后备设置。因此，应检查实际来源选择与配置覆盖文件，不能仅因为主来源连接失败，就断定某个写在 fallback 中的服务器必定已经被尝试。

未同步也不能证明 UDP 流量被阻止。服务可能缺失、未启用、被单元条件排除、没有调整时钟的权限，或者正在拒绝不合适样本。反过来，全局同步属性也不能单独说明哪个进程提供了时间。应区分管理器看到的服务状态、客户端观察到的样本，以及内核层同步指示，避免把来自不同层面的一个布尔值当成完整故障结论。

快速验证

这个失败模式实验在一次性 Debian 12 Docker 容器中以 root 运行，PID 1 为 systemd 252.39。初始化进程通过 /usr/bin/setpriv --bounding-set=-sys_time,-sys_module /sbin/init 启动，移除相关能力以防止调整 Docker 虚拟机共享时钟。脚本在请求任何服务启动前检查该前提，并要求安装包中的容器排除条件存在：

from pathlib import Path
import json,subprocess

def run(*args):
 result=subprocess.run(args,text=True,capture_output=True,timeout=10)
 assert result.returncode==0,(args,result.stderr)
 return result.stdout.strip()
def properties(unit):
 output=run('systemctl','show',unit,'-p','ActiveState','-p','SubState','-p','MainPID','-p','ConditionResult')
 return dict(line.split('=',1) for line in output.splitlines())
# This failure-mode exercise requires an isolated container that cannot set time.
status=dict(line.split(':',1) for line in Path('/proc/1/status').read_text().splitlines() if ':' in line)
assert int(status['CapBnd'].strip(),16)&(1<<25)==0,'PID 1 must lack CAP_SYS_TIME'
assert run('systemd-detect-virt','--container')=='docker'
unit='systemd-timesyncd.service';definition=run('systemctl','cat',unit)
assert 'ConditionCapability=CAP_SYS_TIME' in definition
assert 'ConditionVirtualization=!container' in definition
assert properties(unit)['ActiveState']=='inactive'
run('systemctl','start',unit)
state=properties(unit)
assert state=={'MainPID':'0','ActiveState':'inactive','SubState':'dead','ConditionResult':'no'},state
clock=dict(line.split('=',1) for line in run('timedatectl','show','-p','CanNTP','-p','NTP','-p','NTPSynchronized').splitlines())
assert all(value in ('yes','no') for value in clock.values())
print('start command returned zero; unit stayed inactive with PID 0 and failed conditions')
print('clock properties:',json.dumps(clock,sort_keys=True))
print('PID 1 lacks time-setting capability; Docker condition also excludes this packaged service')
print('no clock-setting command was issued and no NTP synchronization was claimed')

启动命令返回零，但单元仍为非活动，主进程编号为零，ConditionResult=no。条件不满足而跳过激活，与守护进程成功运行，是不同结果。样本安装包要求调整时间的能力，并排除容器，而当前环境两项前提都不满足。因此在假设 NTP 报文被网络丢弃之前，就已经有具体证据解释服务为何没有工作。

记录中的时钟属性为 CanNTP=yes、NTP=no、NTPSynchronized=no，分别反映时间服务接口的不同方面。尤其是系统具有 NTP 服务支持，不代表该服务当前活动，也不证明时钟已经同步。脚本输出真实取值，不会把结果替换成预设健康状态；在另一环境中判断时，也应核对当时实际观察，而不是照抄本例的布尔值。

实验没有发出设置时钟的命令，也不声称成功交换 NTP 报文或完成校时。它验证的是一个没有调时权限的容器中的真实激活失败模式。要测试成功校时，需要具备相应权限、可以访问合适时间源的机器，或拥有独立时钟的虚拟机；不能让宿主共享时钟承担一个没有隔离边界的试验，也不能把未运行的客户端写成同步成功。

守护进程真实运行时，可以通过 timedatectl timesync-status 查看客户端自己的服务器与同步信息。但依赖这个接口之前，应先核对服务状态；请求不可用服务时，可能等待 D-Bus 激活并最终超时。本次容器探测达到五秒观察上限，结果被记为没有获得证据，而不是成功同步检查。接口存在、调用返回与内容证明什么，也需要分别判断。

建立能够验证的时间要求

按网络环境选择时间源，并持续观察偏移、延迟与所接受来源的质量。能够连接，并不让服务器自动准确或可信。轮询和根距离设置影响样本处理，但不能仅靠几个配置就把精简客户端变成完整时间分发服务，也不会自动形成某个精度服务承诺。需要什么精度、怎样观察偏差，应由实际应用要求决定。

保存的 /var/lib/systemd/timesync/clock 时间戳，有助于缺少可靠硬件时钟的系统在重启时初始化时间。但它也可能在近期没有成功同步时被周期更新，因此文件存在不证明刚刚接受了网络样本。大致初始化时间与同步到参考时钟，是两个不同里程碑，不应在开机就绪判断中混为一谈。

如果后续工作必须等到时钟同步，应配置并验证相应等待服务，以及排在 time-sync.target 之后的关系。仅启动 timesyncd，不会自动阻止所有应用在准确参考时间到达前运行。应明确启动条件和运行期监控，并以真实部署环境中的证据为准，而不是依赖一个笼统的“NTP 已开启”标签来判断所有时间相关要求已经满足。

来源

systemd 252 systemd-timesyncd.service，SNTP 行为、大偏差跳时、保存的时钟状态与同步信号，已核验 2026-09-12。
systemd 252 timesyncd.conf，时间源选择、后备来源优先级、轮询与根距离限制，已核验 2026-09-12。
systemd 252 org.freedesktop.timedate1，NTP 可用性、启用状态与内核同步属性，已核验 2026-09-12。
systemd 252 systemd-time-wait-sync.service，在确认时间同步后启动依赖服务，已核验 2026-09-12。

时间戳需要明确的时间语义

Sun, 29 Nov 2026 00:00:00 +0000

像 2026-11-01 01:30 这样的钟表标签，单独存在时不能确定唯一瞬间。解释它需要知道所在时区，在时钟回拨期间还可能需要说明是哪一次出现。反过来，已经明确纪元和单位的 Unix 时间戳，即使没有显示时区名称，也可以具有完整的瞬间语义。选择字符串格式之前，应先明确系统保存的究竟是哪一种时间值。

偏移不是完整时区规则

带数值偏移的时间戳说明本地字段如何对应 UTC。同一天的 12:00Z 和 20:00+08:00 可以表示同一瞬间。IANA 命名时区还包含历史及未来的民用时间规则，包括夏令时切换。安排下个月的洛杉矶本地约会时，固定的负七小时偏移不能替代 America/Los_Angeles，因为到时可能适用不同偏移。

对于已经发生的事件，可以保留无歧义瞬间，再按照读者需要的时区显示。但“每个工作日早上九点”是重复的民用时间意图，还需要保留本地日程及其适用时区。政策变化可能改变未来规则，需要可复现性时也应记录所用时区数据库版本。把今天的偏移固化成永远使用的日程，会悄悄改变原始业务含义。

UTC 格式并不证明时钟准确，也不证明因果顺序。两台机器都能打印 Z 后缀，但各自系统时钟仍可能有偏差；有限精度还会让多个事件得到相同时间戳。需要排序依据时，应保留事件标识及适当的因果上下文。本机经过时长则应选用合适的单调时钟，不能期待时区转换修复最初就测错的瞬间。

数值接口还必须注明采用秒还是毫秒，以及从哪个纪元开始计数。一个较大的整数本身不能完整说明单位；接收方把单位解释错了，之后再切换显示时区也无法恢复正确含义。单位应属于接口契约，而不是靠字段长度临时猜测。

坏掉的样子

任意时间戳字符串直接排序，可能得到与时间先后相反的结果。RFC 3339 对适合文字排序的条件有明确说明，包括统一的时区表示和小数精度。面对混合偏移，应先解析并归一化到瞬间，再进行比较。视觉上本地小时较晚的记录，换算到 UTC 之后可能反而更早，因此字符串字符比较不能替代时间语义解释。

秋季回拨可能让同一个本地小时出现两次，Python 的 ZoneInfo 通过 fold 区分这两个实例。春季前拨则可能让某个本地时刻根本不存在。仅仅把时区对象附到日期上，并不会自动拒绝缺失时间。接受本地约会输入的程序必须定义拒绝或解决歧义的策略，不能悄悄替用户猜测他想选择哪一个瞬间。

日期运算也要与目标一致。两个 datetime 共享同一个 tzinfo 时，相关运算可能使用钟表字段语义，忽略 fold 所表达的瞬间区别。如果需要比较实际经过时间，应先分别转换到 UTC。这个选择需要明确，因为跨越时钟切换时，本地表盘读数之差可能与真正经过的秒数不同，二者都不能无条件替代另一种含义。

快速验证

将下面程序保存为 timezone.py，使用 Python 3.11 或更新版本执行 python3 timezone.py，并确保环境中有 IANA 时区数据。实测环境是 Python 3.11.2 和 Debian tzdata 2026b。程序全部使用固定日期，不会修改机器的时钟，也不会更改系统时区；不同数据库版本需要重新检查相应规则。

from datetime import datetime, timezone
from zoneinfo import ZoneInfo
import json


def instant(text):
 value = datetime.fromisoformat(text)
 if value.tzinfo is None:
 raise ValueError('an instant requires an explicit offset')
 return value.astimezone(timezone.utc)


same = ['2026-09-13T12:00:00Z', '2026-09-13T20:00:00+08:00']
assert instant(same[0]) == instant(same[1])
values = ['2026-01-01T10:00:00+02:00', '2026-01-01T09:30:00+00:00']
assert sorted(values) != sorted(values, key=instant)
try:
 instant('2026-09-13T12:00:00')
except ValueError as error:
 rejection = str(error)
else:
 raise AssertionError('ambiguous instant accepted')

zone = ZoneInfo('America/Los_Angeles')
first = datetime(2026, 11, 1, 1, 30, tzinfo=zone, fold=0)
second = first.replace(fold=1)
first_utc, second_utc = first.astimezone(timezone.utc), second.astimezone(timezone.utc)
assert (second_utc - first_utc).total_seconds() == 3600
missing = datetime(2026, 3, 8, 2, 30)
round_trips = []
for fold in (0, 1):
 candidate = missing.replace(tzinfo=zone, fold=fold)
 returned = candidate.astimezone(timezone.utc).astimezone(zone)
 assert returned.replace(tzinfo=None) != missing
 round_trips.append(returned.isoformat())
print(json.dumps({'same_instant': True, 'lexical_order': sorted(values),
 'instant_order': sorted(values, key=instant), 'naive_rejected': rejection,
 'repeated_wall_time': [first.isoformat(), second.isoformat()],
 'actual_separation_seconds': 3600, 'nonexistent_time_round_trips': round_trips}))

第一项断言确认两个不同偏移的表示指向同一瞬间。随后，文字排序把 09:30+00:00 放在 10:00+02:00 前面，而按瞬间排序会正确地反过来。辅助函数还会拒绝没有偏移的值，不会借用运行机器的当前时区来补足信息。这只是用于示例的小型瞬间解析函数，并不是完整的 RFC 3339 格式验证器。

对于洛杉矶 2026 年十一月一日，两次 01:30 分别带有负七小时和负八小时偏移。转成 UTC 后，实际间隔为三千六百秒。对于三月八日 02:30，两个 fold 候选经 UTC 往返转换都不能保留原本的本地字段，结果分别落在 03:30 和 01:30，说明这个本地标签在当天没有对应的有效瞬间。

全部断言已运行通过。这些案例验证的是已安装数据库中的特定转换规则，并不承诺所有地区永远保持今天的制度。数据契约应分别保留瞬间含义、本地日程意图以及解析政策，避免在显示、存储和调度之间无意丢失决定时间意义的信息。

来源

RFC 3339: Date and Time on the Internet，带偏移的时间戳及字符串排序条件，已核验 2026-09-13。
Python: datetime，带时区值、UTC 转换与日期运算，已核验 2026-09-13。
Python: zoneinfo，IANA 规则、重复时间与 fold，已核验 2026-09-13。

时钟同步约束机器之间的时间偏差

Wed, 09 Sep 2026 00:00:00 +0000

时钟同步用于减少机器之间的民用时间读数差异，支撑证书有效期检查、事件时间解释以及许多过期策略，但不会建立完美的全局时钟。一台主机能够输出格式正确的 UTC，同时仍然测量了错误瞬间。应用需要区分经过时长、绝对截止时间和因果顺序，不能让所有语义都依赖未经解释的钟表数值比较。

四个时间戳估算两个量

一次 NTP 交换包含客户端发送时间 T1、服务端接收时间 T2、服务端发送时间 T3 和客户端接收时间 T4。常用偏移估计为 ((T2-T1)+(T3-T4))/2，正值表示服务端看起来比客户端更快。往返延迟估计为 (T4-T1)-(T3-T2)，其中减去了服务端处理所花的时间。它们是根据观测推算的量，并没有直接测出每一段单向网络路径的时延。

当去程和回程延迟不同，偏移估计就会包含误差。较小的往返延迟有参考价值，却不能证明两个方向完全对称。同步守护进程会使用多次采样、来源选择、过滤和时钟模型，而不是把单个报文当作无条件可信的真相。来源可达性、估计不确定性和来源可信度都需要考虑，较低的 stratum 数字本身并不是精度证书。

时间戳的表示分辨率也不同于测量准确度。小数字段即使能编码非常细的步长，实际时钟或网络观测仍可能带有明显更大的不确定性。多打印几位小数不会改善证据质量，解释结果时应同时说明测量方法和它能够支持的结论。

时钟控制是后续的另一阶段。守护进程可以逐渐调整，也可以在配置允许的条件下直接跳变。因此不能保证 NTP 永远不会造成实时时钟的不连续，更不能承诺所有环境都达到亚毫秒精度。网络、振荡器、平台和配置共同决定实际效果。告警阈值应来自应用需求和测量条件，而不是把某个固定偏差值无条件推广到所有系统。

坏掉的样子

实时时钟可能向前或向后调整，直接相减得到的时长就可能失真甚至变成负数。本机持续时间和超时应选择适当的单调时钟，但其参考起点不能直接当成其他主机或下次启动仍可使用的时间戳。证书日期和业务截止时间仍需要民用时间语义，因此单调时钟并不是替代所有日期处理的通用答案。

格式不完整、与请求不对应、来源未同步或被策略拒绝的 NTP 响应，都不能当成普通样本使用。核对返回的 origin 时间戳是否匹配本次请求，有助于拒绝无关报文，但并不构成密码学认证。生产客户端还需要协议规定的更多校验和来源选择行为。时钟同步也不能自动让基于时间戳的租约成为安全分布式锁，更不能保证非常接近的事件按时间排序就等于因果顺序。

快速验证

使用全新的临时 Debian 12 Docker 容器，先执行 apt-get update，再执行 apt-get install -y python3 chrony 准备依赖。将代码保存为 ntp-exchange.py，以 root 运行 python3 ntp-exchange.py。实测版本是 chrony 4.3 和 Python 3.11.2。创建容器时应去掉 SYS_TIME 能力，并保持独立网络命名空间，不使用宿主网络；实验只需要容器内的回环通信。

from pathlib import Path
from tempfile import TemporaryDirectory
import json
import os
import socket
import struct
import subprocess
import time

assert os.geteuid() == 0 and Path('/.dockerenv').exists(), 'use a disposable root Linux container'
NTP_EPOCH = 2208988800
ERA = 2**32


def stamp(unix_time):
 value = unix_time + NTP_EPOCH
 whole = int(value)
 return struct.pack('!II', whole % ERA, int((value - whole) * ERA))


def seconds(data, reference):
 whole, fraction = struct.unpack('!II', data)
 era = round((reference + NTP_EPOCH - whole) / ERA)
 return whole + era * ERA - NTP_EPOCH + fraction / ERA


def estimate(t1, t2, t3, t4):
 return ((t2 - t1) + (t3 - t4)) / 2, (t4 - t1) - (t3 - t2)


def validate(data, sent):
 if len(data) < 48:
 raise ValueError('short packet')
 if data[0] >> 6 == 3:
 raise ValueError('unsynchronised source')
 if (data[0] & 7) != 4 or ((data[0] >> 3) & 7) != 4:
 raise ValueError('unexpected mode or version')
 if not 1 <= data[1] <= 15:
 raise ValueError('unusable stratum')
 if data[24:32] != sent:
 raise ValueError('origin timestamp mismatch')


with TemporaryDirectory(prefix='ntp-exchange-') as directory:
 root = Path(directory)
 with socket.socket(socket.AF_INET, socket.SOCK_DGRAM) as reservation:
 reservation.bind(('127.0.0.1', 0))
 port = reservation.getsockname()[1]
 config = root / 'chrony.conf'
 config.write_text(f'pidfile {root}/pid\ncmdport 0\nbindcmdaddress {root}/command.sock\n'
 f'port {port}\nbindaddress 127.0.0.1\nlocal stratum 8\nallow 127.0.0.1\n')
 process = subprocess.Popen(['chronyd', '-x', '-n', '-u', 'root', '-f', str(config)],
 stdout=subprocess.PIPE, stderr=subprocess.PIPE)
 try:
 deadline = time.monotonic() + 5
 while not (root/'command.sock').exists():
 assert process.poll() is None
 if time.monotonic() > deadline:
 raise AssertionError('chronyd did not start')
 time.sleep(0.05)
 with socket.socket(socket.AF_INET, socket.SOCK_DGRAM) as client:
 client.settimeout(5)
 client.connect(('127.0.0.1', port))
 request = bytearray(48)
 request[0] = 0x23
 t1, start = time.time(), time.monotonic()
 sent = stamp(t1)
 request[40:48] = sent
 client.send(request)
 data = client.recv(512)
 t4, finish = time.time(), time.monotonic()
 validate(data, sent)
 t2, t3 = seconds(data[32:40], t1), seconds(data[40:48], t1)
 offset, delay = estimate(t1, t2, t3, t4)
 assert data[1] == 8 and finish >= start
 bad_origin = bytearray(data); bad_origin[24:32] = bytes(8)
 alarm = bytearray(data); alarm[0] |= 0xC0
 denied = bytearray(data); denied[1] = 0
 rejected = []
 for candidate in (data[:40], bad_origin, alarm, denied):
 try:
 validate(candidate, sent)
 except ValueError as error:
 rejected.append(str(error))
 else:
 raise AssertionError('invalid packet accepted')
 symmetric = estimate(100, 105.020, 105.022, 100.042)
 asymmetric = estimate(100, 105.010, 105.012, 100.042)
 assert abs(symmetric[0] - 5) < 1e-9 and abs(symmetric[1] - 0.040) < 1e-9
 assert abs(asymmetric[0] - 4.990) < 1e-9 and abs(asymmetric[1] - 0.040) < 1e-9
 print(json.dumps({'actual_loopback_sample': {'stratum': data[1],
 'offset_seconds': offset, 'delay_seconds': delay,
 'monotonic_elapsed_seconds': finish-start},
 'rejected_packets': rejected,
 'synthetic_symmetric_estimate': list(symmetric),
 'synthetic_asymmetric_estimate': list(asymmetric),
 'known_synthetic_offset': 5,
 'system_clock_adjustment_disabled': True,
 'external_UTC_accuracy_tested': False}))
 finally:
 process.terminate()
 process.communicate(timeout=5)

程序用 -x 启动 chronyd，明确禁止调整系统时钟，再配置仅供本地使用的 local stratum 8 来源。它发送真实的第四版客户端报文，检查响应模式、层级、origin 时间戳及告警状态。预期获得层级为八的实际样本，偏移和延迟数值会随运行条件变化。随后四份被改动或截短的报文分别被拒绝，最终关闭套接字与守护进程，不留下后台服务。

另外两个合成计算案例把真实服务端超前量都设为五秒。去程与回程各二十毫秒时，估计结果是五秒，网络往返延迟四十毫秒。改为去程十毫秒、回程三十毫秒后，往返仍为四十毫秒，估计超前量却变成 4.990 秒。十毫秒误差来自路径对称性的假设；这些固定数值是计算案例，不能写成实际回环链路的测量结果。

全部断言已经执行通过。本地来源共享测试主机的时钟，并没有外部 UTC 参考。实验既没有校准系统时钟，也没有证明外部精度、NTS 认证或完整客户端符合性。诊断记录应始终区分已经观察到的有效交换、带不确定性的估计，以及真正足以支撑生产业务的可信时间。

来源

RFC 5905: Network Time Protocol Version 4，时间戳交换、偏移估算及路径延迟，已核验 2026-09-13。
chronyd 4.3 manual，时钟控制及禁用调整选项，已核验 2026-09-13。
Python: time，实时时钟与单调时钟行为，已核验 2026-09-13。

服务器时间校准需要可观察的依据

Wed, 02 Sep 2026 00:00:00 +0000

时间守护进程只有在实际状态满足应用要求时才真正有用。进程正在运行，仍可能没有可用来源；已经选择某个来源，也可能尚未充分测量，或者来源本身就不正确。时间服务健康应当是一条可观察的链路：来源配置、成功采样、选择状态、不确定性以及实际允许的时钟控制。进程显示绿色，只能覆盖链路最前面的一部分。

读取守护进程实际报告的内容

Chrony 的 tracking 输出分别给出参考来源、层级、最近更新时间、尚未消除的系统时间修正量、估计频率、频率偏斜不确定性、根延迟和根离散度。它们回答不同问题：offset 关注时间差，frequency 关注时钟走速，skew 反映频率估计的不确定性。根延迟与离散度则参与描述参考路径带来的时间不确定性。只挑一个很小的偏移数值，不能概括整个时钟质量。

sources 输出用于观察候选来源及实际选择。常见显示中的 ^* 表示选中的 NTP 服务器。Reach 是八进制历史位图，377 表示最近八次轮询机会都有成功响应，并不是百分比，也不保证下一次仍然可达。LastRx 有助于查看最近收到的样本已经过去多久。应把来源状态与 tracking 一起读，而不是把进程持续运行时长误认为同步证据。

上游短暂中断后，守护进程可能继续依据已有模型估计时间，但不确定性会随条件变化而扩大。需要根据应用容忍度监控更新时间和误差估计，区分短期维持与无限期可信。多个服务器名称也不必然意味着独立参考，如果它们共享上游或基础设施，仍然可能一起出错。来源选择降低部分故障风险，却不能证明所有上游声明都正确。

今天能够使用的来源，不能证明长时间断联之后启动服务仍然安全。应事先决定业务能否在维持估计期间启动，以及哪项实际测量超过边界就必须阻止启动。还要把这道检查与耗时测量分开：民用时间可能被校正，而超时逻辑需要合适的单调时钟，不能只因同步状态正常就混用两者。

坏掉的样子

容器通常共享宿主的内核时钟，在容器内运行时间服务并不会自然得到一块独立可调的民用时钟。Chronyd 的 -x 模式明确关闭系统时钟控制，但仍保留估计和提供时间服务的能力。因此，客户端可以报告已经同步，系统时钟却并没有被这个进程修正。排查时必须确认实际运行模式，以及哪一层负责宿主时间。

local 指令也容易制造错误信心。它允许 chronyd 在没有外部参考的情况下表现为已同步，可以用于有明确设计的隔离网络安排。但如果只是为了消除告警而启用，就会把缺失参考这一问题隐藏起来。解释 Normal 之前，要核对参考标识以及预期来源政策，不能把某种协议状态直接解释成 UTC 已经准确。

运行检查还需要有意义的限制。Chronyc 的 waitsync 可以等待同步，并可选地限制剩余时间修正量和频率估计偏斜；相应限制为零时，额外约束会被关闭。两个限制都关闭的成功结果，比执行应用专属容忍边界的检查弱得多。即使配置了边界，它也不能替任意上游时钟证明真实性，来源信任仍是另一项要求。

快速验证

使用新的临时 Debian 12 Docker 容器，运行 apt-get update 和 apt-get install -y python3 chrony 安装依赖，将下面代码保存为 chrony-status.py，以 root 执行 python3 chrony-status.py。创建容器时保持独立网络，不使用宿主网络，并移除 SYS_TIME 能力。实测版本为 chrony 4.3 与 Python 3.11.2，代码只在回环地址通信。

from pathlib import Path
from tempfile import TemporaryDirectory
import json
import os
import socket
import subprocess
import time

assert os.geteuid() == 0 and Path('/.dockerenv').exists(), 'use a disposable root Linux container'
with TemporaryDirectory(prefix='chrony-status-') as directory:
 root = Path(directory)
 processes = []
 with socket.socket(socket.AF_INET, socket.SOCK_DGRAM) as reservation:
 reservation.bind(('127.0.0.1', 0))
 port = reservation.getsockname()[1]

 def start(name, extra):
 config = root / (name + '.conf')
 config.write_text(f'pidfile {root}/{name}.pid\ncmdport 0\nbindcmdaddress {root}/{name}.sock\n' + extra)
 process = subprocess.Popen(['chronyd', '-x', '-n', '-u', 'root', '-f', str(config)],
 stdout=subprocess.PIPE, stderr=subprocess.PIPE)
 processes.append(process)
 deadline = time.monotonic() + 5
 while not (root/(name+'.sock')).exists():
 assert process.poll() is None, 'chronyd exited before command socket was ready'
 if time.monotonic() > deadline:
 raise AssertionError('command socket not ready')
 time.sleep(0.05)
 return process

 def command(name, *args):
 return subprocess.run(['chronyc', '-n', '-h', str(root/(name+'.sock')), *args],
 capture_output=True, text=True, timeout=10)

 def tracking(name):
 result = command(name, 'tracking')
 assert result.returncode == 0, result.stderr
 return {line.split(':', 1)[0].strip(): line.split(':', 1)[1].strip()
 for line in result.stdout.splitlines() if ':' in line}

 try:
 client = start('client', f'port 0\nserver 127.0.0.1 port {port} iburst minpoll 0 maxpoll 0\n')
 before = tracking('client')
 before_gate = command('client', 'waitsync', '1', '0', '0', '0.1')
 assert client.poll() is None and before['Leap status'] == 'Not synchronised'
 assert before_gate.returncode != 0
 start('source', f'port {port}\nbindaddress 127.0.0.1\nlocal stratum 8\nallow 127.0.0.1\n')
 assert command('client', 'burst', '4/4').returncode == 0
 deadline = time.monotonic() + 25
 while time.monotonic() < deadline:
 sources = command('client', 'sources').stdout
 after = tracking('client')
 if '^* 127.0.0.1' in sources and after['Leap status'] == 'Normal':
 break
 time.sleep(0.2)
 else:
 raise AssertionError('local source was not selected')
 assert after['Stratum'] == '9'
 after_gate = command('client', 'waitsync', '1', '0', '0', '0.1')
 assert after_gate.returncode == 0
 source_tracking = tracking('source')
 assert source_tracking['Reference ID'].startswith('7F7F0101')
 print(json.dumps({'daemon_alive_while_unsynchronised': True,
 'before': before, 'after': after, 'selected_sources': sources,
 'waitsync_returncodes': [before_gate.returncode, after_gate.returncode],
 'source_reference': source_tracking['Reference ID'],
 'system_clock_adjustment_disabled': True,
 'external_UTC_accuracy_tested': False}))
 finally:
 for process in reversed(processes):
 process.terminate()
 process.communicate(timeout=5)

程序首先启动一个指向尚无人监听端口的客户端。进程仍然存活，但 tracking 显示 Not synchronised，只尝试一次的 waitsync 返回失败。随后启动另一进程，以 local stratum 8 提供本地来源，要求客户端突发采样，并等待实际选中它。客户端最终显示 ^* 127.0.0.1、层级九和 Normal；同一个等待检查此时返回成功。

两个进程全程都禁用时钟调整，结束后都会停止。本次记录的初始选择阶段，频率估计的 skew 仍然很大，即使同步等待检查已经通过。来源参考标识为 7F7F0101，说明它工作在本地参考模式，而不是已经连接外部 UTC 来源。程序保留完整输出，避免只截取绿色状态后把这些限制丢掉。

原先记录报告全部断言执行成功，本轮审阅没有重新运行这项使用套接字的实验。没有测试外部 UTC 精度、长时间收敛、丢失来源后的恢复或真实时钟修正。这个反例用于说明监控必须分开解释进程可用性、同步状态、质量边界和时间权威。真正上线时应针对业务要求验证这些层次，不能把一个简单成功退出码写成全部时间保障都已经成立。

来源

chronyc 4.3 manual，跟踪字段、来源选择及 waitsync 阈值，已核验 2026-09-13。
chronyd 4.3 manual，时钟调整及 -x 模式，已核验 2026-09-13。
chrony.conf 4.3 manual，本地参考模式与来源配置，已核验 2026-09-13。
RFC 5905: Network Time Protocol Version 4，同步状态与不确定性，已核验 2026-09-13。
Linux clock_gettime，民用时间与单调时钟行为，已核验 2026-10-15。

时间 · XB 现场笔记

PostgreSQL 时间函数取样于不同的时点

一个事务只有一个开始时刻

语句标记与实时读数

坏掉的样子

快速验证

来源

分别检查 timesyncd 服务状态与时钟证据

坏掉的样子

快速验证

建立能够验证的时间要求

延伸阅读

来源

时间戳需要明确的时间语义

偏移不是完整时区规则

坏掉的样子

快速验证

延伸阅读

来源

时钟同步约束机器之间的时间偏差

四个时间戳估算两个量

坏掉的样子

快速验证

延伸阅读

来源

服务器时间校准需要可观察的依据

读取守护进程实际报告的内容

坏掉的样子

快速验证

延伸阅读

来源