程序员里流传着一句半开玩笑的话：处理时间是最容易让人自信地写错代码的领域。原因在于，人类使用的时间充满了由政治、历史和天文决定的不规则规则——时区在变、夏令时在跳、历法里还藏着各种意外。这些规则没有一条是程序员能凭直觉推导出来的，于是关于时间的 bug 层出不穷。了解这些陷阱，是写出可靠时间代码的前提。
时区不只是简单的偏移
很多人以为时区就是相对世界时的一个固定偏移，比如"东八区就是加八小时"。但现实复杂得多：同一个偏移可能对应多个地区，同一个地区的偏移可能随历史变化，有些地方还使用不是整小时的偏移。时区本质上是一套随时间和地点变化的规则，而不是一个常数。
这意味着你不能简单地"给时间加几个小时"来做时区转换，而必须依赖一个维护着所有这些规则的时区数据库。把时区当成常数，是大量时间 bug 的源头。
夏令时制造的混乱
夏令时是时间处理里最臭名昭著的陷阱。在切换的那一刻，本地时间会突然向前跳一小时，或向后退一小时。前者意味着某段本地时间根本不存在——它被直接跳过了；后者则意味着某段本地时间出现了两次，无法唯一确定对应哪个绝对时刻。
这给定时任务、闹钟、计费、日志排序都带来麻烦。一个在夏令时切换点附近调度的任务，可能不执行、或执行两次。处理这些边界，需要明确的策略，而不能假装它们不存在。
规则会变，且无法预测
更棘手的是，时区和夏令时规则并非一成不变。各国政府会出于各种原因修改它们：开始或停止使用夏令时、调整切换日期、甚至整体改变时区。这些变化往往临时宣布，无法靠算法预测。
所以处理时间不能依赖写死的规则，而要依赖一个会持续更新的时区数据库，并保持它的更新。一旦规则变了而你的数据没跟上，未来时刻的转换就会出错。这是"时间永远在变"的最直接体现。
本地时间是模糊的
由于夏令时的存在，"本地时间"本身可能是有歧义的。当时钟回拨时，某个本地时刻会出现两次；当时钟前拨时，某个本地时刻则压根不存在。如果你的系统只存储本地时间而不带时区信息，就无法可靠地还原出它到底指哪个绝对时刻。
这正是"内部统一存绝对时刻、只在显示时转本地时间"这条原则如此重要的原因。绝对时刻没有歧义，而本地时间充满歧义。把可靠的那个作为存储基准，才能避免无法挽回的混乱。
历法本身也有意外
除了时区和夏令时，历法本身也埋着坑。闰年的规则比"每四年一次"更微妙；有些场景还会遇到闰秒这种为对齐天文时间而插入的额外一秒。不同文化使用不同历法，甚至历史上还发生过历法改革，导致某些日期"消失"。
大多数应用不必处理所有这些极端情况，但要意识到它们的存在。当你假设"每年都有 365 天"或"每分钟都有 60 秒"时，某些边界场景就可能让你的代码悄悄出错。
跨时区协作的难题
当系统的用户分布在不同时区时，"今天"、"本月"、"凌晨零点"这些概念都变得相对。对一个用户是今天的事件，对另一个用户可能已经是昨天。按日期聚合统计、设置每日额度、安排跨时区会议，都会因此变得微妙。
解决这类问题，需要明确每个"日期边界"到底以谁的时区为准，并在设计之初就把它写清楚。含糊地处理"哪天",往往会在跨时区用户增多后引发难以排查的统计偏差。
把复杂性交给可靠的工具
纵观这些陷阱会发现一个共同结论：时间的复杂性几乎都不该由你手写代码去硬扛。成熟的时区数据库和日期时间库，已经把这些不规则规则一一编码并持续维护。你的任务是正确地使用它们，而不是重新发明它们。
记住几条原则：内部统一存绝对时刻，只在显示时转本地，依赖并更新时区数据库，并对夏令时和历法边界保持警惕。把复杂性交给可靠的工具，你就能避开处理时间时那些最常见、也最令人崩溃的 bug。