用边界情况而不只是理想路径来测试位置数据
一个位于地图完善的市中心的地址，几乎无法告诉您系统如何处理乡村路线、有争议的边界或靠近两极的查询。请有意识地测试这些困难情况。
更改过时区规则的国家
人们很容易认为，一旦知道了某个国家的时区，就可以一劳永逸。但实际上，政府调整时区政策的频率比大多数人意识到的要高。一个国家可能在实行夏令时几十年后决定停止实行。另一个国家可能把标准偏移量调整一小时，以便与主要贸易伙伴更加一致。一个大国可能随着地区行政区划的变化，重新划定其两个时区之间的内部边界。这些都不是假设的类别。这类变化在世界某个地方相当有规律地发生，尽管对于任何一个国家来说，两次变化之间可能相隔数年甚至数十年。
这正是 IANA 时区数据库要解决的问题。它不是为每个国家存储一个当前偏移量，而是把每个命名时区作为一段随时间变化的规则历史来记录，每当某国政府宣布变更时就添加新条目。从一份持续维护、定期更新的数据库副本中读取数据的软件，无需修改自身代码就能获取这些变化。而按国家硬编码偏移量的软件，比如在初始开发时写好的一张查找表，会在下一次任何相关国家修改规则时悄悄出错，而且这种故障不会自我暴露。它只会开始为那个国家返回错误的当地时间，直到有人注意到为止。
这也是为什么对于任何需要使用超过几个月的数据，单独存储一个脱离命名时区的 UTC 偏移量是有风险的。今天记录的偏移量只是某条可能改变的规则的快照。而像 Pacific/Auckland 或 Asia/Kolkata 这样的时区名称，带有对持续维护的规则集的引用，因此只要底层数据库保持最新，即使规则发生变化，基于该名称的计算也会保持正确，而您无需改动自己的数据。
对于任何基于时区数据进行开发的人来说，实用的建议很简单。在您自己的数据库中存储时区名称，而不是原始偏移量。按合理的周期更新您所依赖的时区库或数据源，因为一旦某个相关国家修改规则，一份过时的副本的表现就与硬编码的表格完全一样。对于与真实、不断变化的日期相关的计算，要把时区查询当作需要即时调用的操作，而不是可以无限期缓存的值。
我们的时区查询针对任意坐标返回当前的 IANA 时区名称和偏移量，基于持续维护的规则集计算，而不是静态表格，这是在各国随时间调整自身规则的情况下保持正确的唯一方法。