永不过期的 API 密钥带来的问题
一个多年前签发、从未轮换、至今仍然有效的密钥并不是一种便利。它是一个多年来没有人真正检查过的隐患。
为什么时区错误通常是测试问题，而不是数据问题
时区错误几乎从不会在一个普通的星期二出现。它会在夏令时切换的那一周出现，或者出现在某个政府刚刚在几乎没有预告的情况下更改了偏移规则的地区，或者出现在两个时区的交界处，那里坐标到时区映射中的某个边界情况选错了一边。一年中的其他时间，时区处理得很糟糕的代码运行起来没有任何可见的问题，而这恰恰是这类错误如此顽固的原因：这种失效模式按其本质就很少发生，因此在真正于生产环境中发生之前很少被发现。
我们认为，这些错误大多被归咎于数据，而实际上是测试上的缺口。IANA 时区数据库是包括我们在内的大多数严肃时区处理的基础，它会在这些切换和规则变化发生时进行跟踪。数据可用，并不等于应用正确地执行了那些只在切换周运行、或只适用于少数规则特殊地区的代码路径。如果一套测试从不模拟夏令时边界，或者从不对采用非标准的半小时或 45 分钟偏移的地区运行查询，那么底层数据正确也无法让应用免于一个只有它自己未经测试的代码路径才能防止的错误。
在这种情况下，解决办法枯燥而具体，而不是令人兴奋：明确针对发生切换的日历日期进行测试，而不只是针对某个因为方便而随意挑选的日期。有意识地针对少数几个偏移特殊的边界情况地区进行测试，而不只是针对大多数开发工作恰好所在的那些常见的整点时区。这些都不需要新的数据。它需要的是认定那罕见的一周值得像常见的时候一样仔细测试，因为那罕见的一周恰恰就是错误会在真实用户面前暴露的时候。
还有一个相关的陷阱值得指出：为某个位置缓存一次时区偏移，然后无限期地重复使用这个缓存值。一个在七月正确的偏移，在十二月可能就因为夏令时的调整而变得错误，而一个没有考虑到这一点的缓存，会自信地提供一个过时的答案，没有任何迹象表明出了问题。这同样不是数据质量问题。这是一个架构决策，它假定某个事实会保持不变，而这类数据的全部本质恰恰就在于它会周期性地改变。
我们把自己的时区端点描述为产品中完全可用的部分之一，因为底层参考数据得到积极维护，而且查询逻辑的构建直接考虑了这些切换，而不是假定一个静态偏移。更大的观点不限于我们自己的产品：一个到达客户那里的时区错误，很少能证明源数据是错的。它更常证明的是，没有人为一年中规则真正发生变化的那一周或那一个地区编写测试。