前阵子写了段超时逻辑，思路直白：记下开始 t0 = now()，任务跑完取 t1 = now()，t1 - t0 超阈值就判超时。自测过了就上线。
严格来说后来某台机子 NTP 校时把时钟往回拨了几秒，t1 比 t0 还早，差值直接成负的。有的任务被误判"提前完成"跳过后续，有的卡在等待里出不来。墙上时钟（wall clock）本就会因 NTP、夏令时跳变，拿它度量间隔，前提就不成立。
翻 POSIX 和 Python 文档才确认，量耗时该用单调时钟（CLOCK_MONOTONIC / time.monotonic()），只增不减、不受校时干扰。从某种角度看，这坑不深，可前提一错，下游全歪。你们量间隔都用哪种时钟？
夏令时那一跳才离谱 我日历之前被校时带歪 约好的饭局直接排到前一天 差点放朋友鸽子哈哈哈哈
哎，自测都过了还被墙钟摆了一道，换谁都郁闷。不过你那句"前提一错下游全歪"真通透，想明白人就松快了。别担心，下次稳稳的
读到 t1 比 t0 还早那句，心里忽然动了一下。我们太习惯把"时间"当成一条只往前淌的河了，却忘了机器里那口钟也是会回头看的——NTP 轻轻一拨，几秒便倒流回去。子曰"逝者如斯夫"，可连逝者都不总如斯。
你那句"前提一错，下游全歪"说得真安静，也真沉。我们写下的每一行逻辑底下，都垫着一些从没说出口的"当然如此"：当然时间是单调的，当然灯会亮，当然等的人会回来。可这些当然，哪一个经得起被拨回去几秒呢。怎么说呢
单调时钟是个干净的答案。只是生活里那些靠不住的前提，往往没有 time.monotonic() 可换。
后来是把全线都换成单调时钟了，还是只先按住那台出问题的机子？
t1 比 t0 还早的那几秒，读到这里我心里轻轻咯噔一下。像你正低头走一段很长的夜路，再抬头时路牌指向和记忆里反了，不是你走偏了，是地面被人趁你不注意挪过。
你那句"前提一错，下游全歪"，说得那样安静，却比任何一行报错都沉。我们总默认"现在"是个可靠的词，可墙上的钟原就是个会撒谎的邻居，NTP 来敲个门它就改主意，夏令时一来它就跳一格。拿它去量一段距离，量出来的从不是距离，是两个谎言之间的缝。c’est la vie，可拿会回拨的钟当尺，量什么都失真。
这让我想起刚摸索着写代码那两年。有回死活查不出一个边界 bug，熬了三晚，末了发现是底层假设里把单位弄混了，毫秒当成了秒。整座上层逻辑都砌在这一个错的前提上，越补越塌。后来才慢慢懂，monotonic 不只是一个时钟函数，更像一种活法：去靠着那些只增不减的东西，去信那些不会被校时拨乱的东西。
日子大概也是这么量的。外头那些标尺，旁人眼里的成功、某张纸、某个跳动的数字，都像墙钟，不知哪天就被什么看不见的手往回拨几秒，教人疑心自己是不是退回去了。可有些东西是单调的：翻过的书页，熬过的长夜，心里一点点长起来的笃定。它们不回头。
你问量间隔用哪种时钟。我倒想反问一句：我们量日子，敢不敢也换一只只增不减的表？
拿 wall clock 量间隔基本等于赌 NTP 不抽风。我早被夏令时背刺过，现在闭眼 monotonic 谁劝都不听 (￣▽￣)
时间还能倒着走一下 这操作我之前真没想过 墙钟这么不靠谱的吗
wall clock 拿来量间隔这件事，前提本身就脆得离谱。你那个 NTP 往回拨的例子其实还算温柔的——至少只是几秒。想想笔记本合盖休眠再开盖，wall clock 一路往前走可机器明明"停"了两小时，这种间隔直接虚高你都发现不了。还有虚拟机迁移，宿主机一切走，guest 时钟说飘就飘。哈哈哈吧
嘿嘿绝了
话说不过 monotonic 也不是银弹，这点想给楼主补一刀：Linux 上 CLOCK_MONOTONIC 虽然不吃 settimeofday 那种跳变，但它会被 NTP 的频率微调 adjtime 带着走，严格说不是"绝对只增不减的物理秒数"。要跟 NTP 完全脱钩得用 CLOCK_MONOTONIC_RAW。当然对绝大多数超时判断 monotonic 已经够 nice 了，adjtime 那点漂移在阈值面前基本可以忽略不计。
另一个反向坑也常见：有人一听 monotonic 好，连"记录事件啥时候发生"也用它，这又拧了。monotonic 的原点是任意的、不可跨进程比较的——进程 A 记的 12345.6 秒，进程 B 重启后可能是 12.3 秒，根本对不到一块。写日志、存库、显示给用户看，还是得 wall clock 配时区。所以核心不是"monotonic 永远对"，而是先想清楚你量的是 duration 还是 timestamp。
嘿嘿
你那句"前提一错下游全歪"我太有共鸣了… 写逻辑时默认 assumption 全是绿勾，等出事回头才发现最底下地基是泥的。sounds like 好多 bug 都长这个 shape 哈哈哈
绝了
跨机器的间隔比较又是另一个深渊，NTP 那点同步误差在分布式超时里能玩出花来，不过那是 another story 了
这坑太真实了，ntp往回拨那次我也被负差值整懵过
想当年我也干过一模一样的事。给一个小服务写超时判断，t1减t0，本地自测跑得欢，结果上线没两天，有台机器被NTP往回拨了几秒，下游一堆任务要么被跳过、要么卡死，查了半天才猛然反应过来，是时钟在背后捣鬼。你帖子里说的monotonic，方向上完全对，我补两句它其实也罩不住的情况。
其实
第一，monotonic只在同机、同运行期里有意义。它没有一个公认的纪元，所以你没法把它存进数据库说这条记录在启动时monotonic值是xxx，也没法拿A机的去减B机的。凡是涉及绝对截止时刻、或者跨机比较，还是得回到墙上时钟，只是得容忍误差、设个上限，别当精确值使。
有一说一
第二，monotonic到底包不包含机器休眠的那段，不同系统口径并不一致。你若想度量的是真实流逝的墙钟时间，得先确认选的接口符不符合预期，别想当然。
我自己的体会是，底层时钟选得再对，逻辑上还是得留后手。间隔算错一次不假，但下游任务最好做成幂等、可重试，状态别全押在一个差值上。时钟只是工具，真正扛事的是你写的流程。
另，现在NTP那套用chrony的slew模式，比老式ntpd直接step友好太多，时钟是慢慢追上去而不是硬跳，这类事故从源头上就少了一截。话不能这么说
你们现在用哪种方案？直接换monotonic，还是顺手把重试逻辑也一起加固了？
我前几年也栽过类似的跟头。跟着人搞创业，前提没想明白就先冲了，往下走每一步都觉得不对劲，又舍不得前面的投入，硬撑到散伙赔了三十万才罢休。看了你的帖子倒觉得，写代码和做事是一个理，墙上时钟本就会跳，你拿它量间隔，根子上的假设就不稳。话不能这么说
monotonic 那个我后来也改成习惯用 time.monotonic() 了，省心。不过话说回来，真要命的往往不是技术选错，是没人愿意在动手前先问一句"我这个前提站不站得住"。你们组 review 会有人揪这种假设么？