编程与软件工程infiniteundo.com编辑精选
程序员对时间抱有的种种错误认知
Falsehoods Programmers believe about Time
2012 — 2022，它一次次回到首页
黑点是上首页（≥ 50 分）的那次投稿，空心点是没冲上去的投稿，点越大分数越高。
导读
这篇文章以清单形式列举程序员对时间的常见错误假设，涉及时区、夏令时、闰秒、单调时钟和历法改革等。它提醒我们：时间远非简单递增的整数，系统时钟、UTC 和日历规则都可能出现反直觉行为。
为什么经久不衰：因为时间相关的边界情况至今仍会制造难以复现的 bug，这份清单简短、具体，适合每次处理时间逻辑前重读。
HN 评论精选
补充了更多时钟可倒退、启动时间和单调时钟并不可靠的反例。
还能补充一些错误假设：1. 时间不会倒退（时区就能打破这一点）。2. UTC 不会倒退（闰秒能打破）。3. 系统启动时间不会变（很多平台把当前时间定义为“启动时间+运行时长”，设置当前时间就是改启动时间）。4. 系统运行时长不会倒退（有些平台通过改运行时长来设置当前时间）。5. POSIX 的 CLOCK_MONOTONIC 不会倒退（在某些平台和虚拟化环境中，CPU 在虚拟机间共享时会失效）。6. 非虚拟化系统上 CLOCK_MONOTONIC 不会倒退（某些平台会因 CPU 间时钟偏移而发生）。
cperciva查看英文原文
Some more falsehoods: 1. Time never goes backwards (as other people have pointed out, time zones break this). 2. UTC time never goes backwards (as other people have pointed out, leap seconds break this). 3. The system boot time never changes. On most platforms, the current time is defined as "boot time plus uptime", and setting the current time is performed by changing the boot time. 4. System uptime never goes backwards. Some platforms handle setting the current time by changing the system uptime. 5. POSIX's CLOCK_MONOTONIC never goes backwards. On some platforms and virtualization environments this can break with CPUs shared between virtual machines. 6. On systems without virtualization, CLOCK_MONOTONIC never goes backwards. On some platforms this can occur due to clock skew between CPUs.
政治与历法变更制造了更多时间陷阱。
它甚至没提到各国政府对时间做过的各种奇怪改动：从本地太阳时改为标准 GMT 偏移时区（会跳过或重复若干分秒）；引入、废除或移动夏令时；偏移 2 小时的“超级夏令时”；跨过国际日期变更线；以及最大的一个——格里高利历改革，不同国家在 1582 到 1920 年代间陆续采用，依据采用时间跳过 10 到 13 天。
brazzy查看英文原文
And it doesn't even mention all the bizarre things that have been done (for reasons good and bad) to time by various governments. Like adjusting from local solar time to standard GMT offset timezones (which involves skipping a given number of minutes and seconds or having them twice). Or introducing/abolishing/moving around daylight savings time. Or "super daylight savings time" with a 2 hour offset. Or moving from one side of the international date line to the other. And of course the real biggie: the Gregorian calendar reform that various countries adopted at different times between 1582 and the 1920s, skipping between 10 and 13 days depending on when they adopted it.
虚拟化和 CPU 时钟源会让时间计算失真，技术细节值得注意。
关于 CentOS 上 KVM 的那条评论可能不准确，不确定它指什么。5.4 左右的内核时期有很多时钟问题，其中一个与频率缩放有关。PC 有多个时间源：CPU 内部时钟以纳秒级高速跳动，墙上时钟以秒级慢速跳动；内部时钟从系统启动时的 0 开始，所以不调整就不能当墙上时钟。Linux 等系统从 RTC 取得启动时间，再加上 CPU 内部时钟来计算当前时间。TSC 可能因频率缩放等原因严重不准；如果主机改变 TSC 频率，直接访问 TSC 的虚拟机客户机不会察觉，时间就会变慢 50%。现代处理器有固定 TSC 频率，KVM 也有半虚拟化时钟源，缓解了问题。Windows 不使用 TSC 作为时间源，通常没这个问题（但有别的问题）。
aliguori查看英文原文
The comment about KVM in CentOS is probably inaccurate--not sure what it's referring to. In the 5.4-ish time scale, there were a lot of clock related problems. One of them had to do with frequency scaling... PCs have many time sources. The processor has it's own internal clock that ticks at a very fast rate (nanoseconds). There's the wallclock time which ticks at a slow rate (seconds). The internal clock starts at 0 when the system boots so it can't be used for wallclock time without adjustment. Some Operating Systems (like Linux), get the boot time from the real time clock (slow tick rate) but then compute the current time by adding the CPU internal clock to it. The CPU internal clock (TSC) can be wildly inaccurate for various reasons. One of them is frequency scaling which actually changes the frequency of the TSC dynamically. Unfortunately, if you're changing the frequency of the TSC on the host, guests that are running and accessing the TSC directly don't realize this has happened. So if you scale the TSC frequency by 50%, time starts moving 50% more slowly. BIOS can also scale processor speed on some servers without the OS knowing which can lead to the same problem on bare metal. More modern processors now have fixed TSC frequencies and KVM now has a paravirtual clock source both which address this problem. BTW, Windows does not use the TSC as a time source so Windows typically won't have this problem (although it has other problems). Time keeping in virtualization is fun :-)
闰秒会带来真实的运营中断，Unix 时间戳难以表达它。
闰秒是个足够大的问题，以至于股票市场会为此休市。Google 会提前数小时推进时钟；电力公司大约要四小时才能跟上（每台 1800 RPM 发电机要多转 30 圈）。很少系统能正确处理 61 秒的一分钟；Unix 时间戳与闰秒根本不兼容。
Animats查看英文原文
Leap seconds are a big enough problem that stock markets shut down for them.[1] Google starts advancing their clocks hours in advance of a leap second. Power companies take about four hours to catch up after one. (Every 1800 RPM generator has to make 30 extra turns.) Very few systems properly handle a 61-second minute. Unix timestamps are fundamentally incompatible with leap seconds. [1] http://money.cnn.com/2015/06/29/technology/leap-second/
历次讨论
同类还值得读
开源应用架构
The Architecture of Open Source Applications
《开源软件架构》（AOSA）是一本在线免费书，邀请知名开源项目的作者亲自剖析其内部设计，涵盖 SQLAlchemy、LLVM、Audacity、Apache、Bash 等系统。
编程与软件工程上首页 9 次 · 2011–2024aosabook.org编辑精选编程语言简史：简短、不完整且多半错误
A Brief, Incomplete, and Mostly Wrong History of Programming Languages
一篇以戏谑、故意不准确的方式回顾编程语言史的博客文章，用夸张轶事和讽刺定义串起 Lisp、C、C++、Java、JavaScript、PHP 等语言。
编程与软件工程上首页 8 次 · 2009–2021james-iry.blogspot.comSQLite 是如何测试的
How SQLite is tested
SQLite 官方文档页，系统介绍 SQLite 的测试体系：多种测试方法（TCL 测试、模糊测试、回归测试、静态分析等）和海量测试用例，展示了这个小型开源项目如何靠极致测试获得…
编程与软件工程上首页 8 次 · 2009–2025sqlite.org编辑精选高级编程语言（2009）
Advanced programming languages (2009)
Matt Might 的经典文章，按用途推荐“高级编程语言”：如果追求就业就选主流语言，如果追求表达力、学术研究或创业，则推荐 Haskell、OCaml、Scala 等函数式语…
编程与软件工程上首页 8 次 · 2009–2022matt.might.net我的 Forth 与栈机器经历
Yosefk - My history with Forth & stack machines
作者以亲身经历回顾了使用 Forth 语言和栈式机器的历程：既赞叹其简洁优雅、代码量小、可自举的优点，也坦率指出栈操作在实际编程中的痛苦，以及 Forth 社区文化中的问题。
编程与软件工程上首页 8 次 · 2010–2024yosefk.com编辑精选