用边界情况而不只是理想路径来测试位置数据
一个位于地图完善的市中心的地址，几乎无法告诉您系统如何处理乡村路线、有争议的边界或靠近两极的查询。请有意识地测试这些困难情况。
时区数据：规则实际上是如何维护的
时区首先是一项政治决定，其次才是地理概念。两个时区之间的分界线、是否实行夏令时的决定，以及时钟向前或向后调整的确切日期，都由国家或地方政府设定，而其中任何一项都可能改变。这就是为什么时区数据不能是一张冻结在过去某个时间点的静态偏移表。它必须是一份持续维护的记录，涵盖历史、现行规则和已知的未来变更。
正是出于这个原因，IANA 时区数据库成为大多数软件所依赖的参考。它的维护者会在各国政府宣布法定时间变更时进行追踪，无论是夏令时政策的调整、某个地区所采用的 UTC 偏移量的变化，还是一个国家内部各时区之间的边界调整。每个命名时区，例如 Europe/Amsterdam 或 America/Chicago，不仅包含当前规则，还包含过去规则的完整历史，因为软件往往需要为过去的某个日期计算正确的偏移量，而不仅仅是今天。
这份历史记录比看起来更重要。几年前的一个时间戳，需要的是那一天实际生效的偏移量，如果规则在此期间发生过变化，它可能与今天生效的偏移量不同。一个只知道当前规则的时区查询，会对历史日期或未来日期悄无声息地给出错误结果，这就是为什么只要日期很重要，就值得向时区 API 查询某个特定时刻所在的时区，而不仅仅是查询时区名称。
这也是为什么时区查询应当返回实际的时区名称，而不仅仅是一个数字偏移量。Europe/Amsterdam 背后承载着全部的历史和夏令时逻辑。+01:00 只在一年中的部分时间正确，而且无法告诉您它何时会改变。只为某个地点存储偏移量的软件，会在下一次夏令时切换发生时偏离正确，而存储时区名称的软件，只要底层数据库保持更新，就能无限期地保持正确。
My Geocode 的时区查询会同时返回 IANA 时区名称和 UTC 偏移量，并接受一个特定的时间点，从而针对那个确切日期应用正确的偏移量（包括夏令时），而不是假定今天的规则一直有效。