用边界情况而不只是理想路径来测试位置数据
一个位于地图完善的市中心的地址，几乎无法告诉您系统如何处理乡村路线、有争议的边界或靠近两极的查询。请有意识地测试这些困难情况。
半小时和 45 分钟时区详解
大多数开发者在编写第一段时区处理代码时，都假定每个偏移量与 UTC 相差整数个小时。这个假设对大多数时区成立，但一旦有请求来自不遵循这一规律的地方，它就会失效。世界上有好几个地区使用半小时的偏移量，至少有一个地区使用 45 分钟的偏移量，而这些都不是罕见或无效意义上的边缘情况。它们只是这些地方根据太阳位置和相邻地区来设定时钟的方式。
半小时偏移量通常反映出一个国家的经度位于两个标准整点时区之间，并决定取其中间值，而不是向某一侧取整。45 分钟偏移量更为少见，往往反映出类似的中间位置，同时刻意选择与相邻的标准偏移量保持区别。两者都不是数据错误，而都是合法的法定时区，在 IANA 数据库中与任何整点时区一样被记录。
真正导致软件出错的，是硬编码了假设的日期和时间运算。将偏移量四舍五入到最近整点的代码、将偏移量存储为整数小时数的代码，或者仅用整点和半小时增量来构建时区下拉列表的代码，都会悄无声息地错误处理这些时区。故障通常也很隐蔽。时间会偏差十五或三十分钟，而不是抛出明显的错误，这使得该缺陷在测试中很容易被忽略，直到受影响地区的真实用户报告问题时才会暴露出来。
如果从一开始就为此做好设计，解决办法很简单：始终使用为某个时区返回的实际 UTC 偏移量，并以分钟精度表示，而不是假定或取整到小时。尽可能存储和比较时区名称而不是偏移量，因为名称本身就包含了准确的当前和历史偏移量，您无需硬编码任何内容。
一个同时返回精确偏移量和 IANA 时区名称的时区查询，可以消除这里的猜测。请直接查询坐标或时区，而不要仅根据国家或地区来推测某个位置的偏移量，因为偏移量在同一个国家内也可能不同，而且很少在所有地方都整齐地对齐到整点。