定时任务、令牌过期、缓存失效、限流、计费周期——大量系统功能都建立在时间之上。可时间又是出了名的难处理：时钟会漂移、会回拨，分布式节点之间还无法保证完全一致。一个对时间假设不当的系统，可能在大多数时候运行良好，却在某些边界条件下突然出错。设计可靠的时间相关系统，靠的是一些务实而稳健的原则，让它在真实世界的种种不确定性里依然站得住。
内部统一用绝对时刻
第一条、也是最重要的一条原则：系统内部存储和传递时间，一律使用与时区无关的绝对时刻，只在面向用户展示的最后一刻才转换成本地时间。绝对时刻没有歧义，便于比较和运算；本地时间充满时区和夏令时的陷阱。
把这条原则贯彻到数据库、接口、日志的每一层，能从根上消除一大类时区相关的 bug。让本地时间只活在展示层，是可靠时间系统的基石。
两种时钟，用途不同
系统里其实有两种时钟。一种是"墙上时钟"，反映当前的真实日历时间，但它可能被同步服务调整，甚至回拨。另一种是"单调时钟"，它只会单向前进、不会回退，适合测量时间间隔。
用错时钟会出微妙的 bug：如果你用墙上时钟来测量某段操作的耗时，而期间时钟恰好被回拨，你可能算出一个负的耗时。测量"过了多久"用单调时钟，记录"什么时候发生"用墙上时钟，分清两者很关键。
时钟不可全信
一个容易被忽视的现实是：服务器的时钟并不总是准确的。它可能漂移、可能被错误配置、在分布式环境里不同节点之间还可能有偏差。如果你的逻辑假设所有时钟都精确一致，就可能在时钟出问题时做出错误判断。
稳健的设计会对时钟的不精确保持容忍。比如在校验过期时间时留出一点余量，避免因为几秒钟的时钟偏差就误判一个本该有效的令牌失效。不要把系统的正确性，押在时钟绝对准确这个假设上。
过期与刷新要留余地
涉及过期的功能——令牌、缓存、会话——都应当考虑时钟偏差和处理延迟。一个恰好在过期临界点的令牌，可能因为签发方和验证方的时钟相差几秒就被误判。在比较时间时引入一个小的容差窗口，能让这类边界更平滑。
同样，刷新机制应当在真正过期之前就提前触发，留出处理和重试的余地，而不是卡着最后一秒。给时间相关的判断留一点缓冲，是务实而非偷懒。
定时任务要能容错
定时任务面对着各种现实的不确定：服务可能在调度时刻宕机、夏令时切换可能让某个时刻跳过或重复、任务本身可能执行得比预期久。一个脆弱的调度器会因为这些情况漏跑、重跑或乱序。
可靠的做法是让任务设计成可重复执行而结果一致，也就是幂等的。这样即便因为时间相关的意外导致某次任务跑了两次，系统也不会出错。把"任务可能不按理想时刻精确执行"当成常态来设计，而不是例外。
分布式环境下别依赖完美同步
在多台机器协作的系统里，假设它们的时钟完全一致是危险的。哪怕有同步服务，节点之间仍会存在微小的偏差。如果你用各节点的本地时间戳来给事件排序，就可能得到错误的顺序。
需要严格排序时，应当借助专门的机制，而不是天真地比较各节点的墙上时钟。理解"分布式时间无法完美同步"这一前提，能让你避开许多在单机上看不出、一上集群就暴露的隐患。
用真实世界的边界去测试
时间相关的 bug 往往只在特定时刻出现，平时根本测不到。因此要主动用那些麻烦的场景去测试：夏令时切换的瞬间、跨年跨月的边界、时钟被回拨的情况、不同时区的用户。把这些刻意构造出来，问题才会在上线前暴露。
归根结底，可靠的时间系统不是靠运气，而是靠对时间不确定性的清醒认识和务实应对。统一用绝对时刻、分清两种时钟、容忍时钟偏差、让任务幂等、不依赖完美同步——把这些原则落实下来，你的系统就能在真实世界纷繁的时间规则里稳稳运行。