用边界情况而不只是理想路径来测试位置数据
一个位于地图完善的市中心的地址,几乎无法告诉您系统如何处理乡村路线、有争议的边界或靠近两极的查询。请有意识地测试这些困难情况。
地球的自转并非完全恒定,而协调世界时(几乎所有民用计时的基础)是以一个非常精确的原子标准来定义的,而不是以地球实际的、略有不规则的自转来定义。为了防止 UTC 随着时间推移偏离地球的真实自转,偶尔会插入额外的一秒,即闰秒,这就是为什么 UTC 与其所依据的严格原子时标准会非常缓慢地产生偏差,然后定期被校正回一致。
对于几乎所有涉及时区或时间戳的应用来说,这只是一个冷知识,而不是实际问题。闰秒是一种极其罕见、经过刻意安排的事件,绝大多数软件,包括几乎所有基于标准操作系统时钟构建的软件,都会在系统层面透明地处理它,远在您的应用代码看到时间戳之前。除非您所从事的领域专门要求在长时间跨度上进行亚秒级精度的计时,例如某些科学、金融或卫星导航系统,否则您极不可能写出会因闰秒而表现不同的代码,而这类软件在整体上确实只占很小一部分。
闰秒偶尔确实会成为真实(尽管通常很小)的工程问题,那就是在跨越闰秒边界进行非常精确的时长计算的系统中:如果朴素的时间运算没有考虑这一调整,结果就可能恰好相差一秒。大多数通用应用,也就是任何出于普通业务目的、以整秒或更大单位计算时长的应用,永远不会察觉,因为一秒的偏差完全在几乎所有日常用例的容差范围之内。
之所以在这里提到它,主要是因为它补全了民用时间实际运作方式的完整图景,而在实践中更重要的夏令时切换和时区规则变更,则在其他文章中有所介绍。闰秒是 UTC 维护方式中一个真实而有趣的特点,但对于绝大多数应用来说,您并不需要围绕它构建防御性逻辑,包括几乎所有使用我们的时区查询来处理位置、日程安排或时间戳的应用。如果您的特定领域确实要求在长时间跨度上具备亚秒级计时精度,那是一个值得明确、单独处理的专门问题,远远超出了典型位置感知软件的范围。