在结账前核对地址与所填邮政编码是否一致
订单表单上邮政编码与城市不一致，看起来只是个小笔误，直到包裹被送到国内完全不同的地方。
跨时区协调远程团队
“UTC 减五小时”不是一个时区，而是一个偏移量，而在大多数实行夏令时的国家，偏移量每年会变化两次。这正是一个十二人远程团队安排的会议几个月来一直准确、然后突然出错的原因，而出错恰好发生在一次负责排期的人谁都没想到去核对的时钟调整前后。
这个团队一直维护着一张简单的表格，把每位成员所在的城市对应到相对于公司总部的一个固定时差，每当有人想起夏令时快到了，就手动更新一次。这张表格一年中大约有六个月是错的，而且错的地方轮流变化，取决于哪些国家已经调整了时钟、哪些还没有，因为并非每个国家都按相同的时间表实行夏令时，有些国家根本不实行。
解决办法是用一个反映真实时区规则的查询取代这张表格，而不是依赖某人曾经输入的一个快照。团队为每位成员所在的城市解析出一个坐标，并将其发送到 /v1/timezone，该端点返回这个位置的 IANA 时区名称，例如“America/Sao_Paulo”或“Asia/Kolkata”，而不是一个单纯的偏移量。这个名称本身就带有该地区实际的夏令时规则，因此一个存储 IANA 名称并据此计算当前偏移量（而不是直接存储偏移量）的排期工具，会在时钟调整时自动保持正确，因为规则存放在时区数据库中，而不是存放在某个需要有人记得去更新的值里。
团队把这一功能直接接入了会议排期工具，这样在提议一个会议时间时，每位参会者的当地时间都能正确显示，并且是在安排会议的那一刻重新计算的，而不是从静态表格中读取。对于提前数周提议的会议，端点能够针对未来某个特定时刻计算偏移量这一点也很重要，因为在某个地区时钟调整之前安排、调整之后举行的会议，需要的是调整后的正确偏移量，而不是安排当天生效的偏移量。
显而易见的变化是排期错误减少了，因为会议落在某人不合理时间而发出的致歉消息也少了。不那么显眼的变化是，团队里再也没有人需要记住四个国家的夏令时时间表，而这在以前确实是某个人非正式的、无偿的职责。
这种解决办法既能轻松扩大规模，也能轻松缩小规模。十二人的团队和一千人的公司面对的是同一个根本问题，只是体量不同，而查询本身的复杂度无论哪种情况都不会改变，改变的只是调用频率。对于一个小团队来说，用量轻松落在密钥附带的每日免费额度之内，因为每天几次解析十几个人的时区，与每天可用的 2,500 次免费请求相比，只是微不足道的工作量。
时区缺陷通常在造成实际问题之前都不会显现，而一旦显现，损失就是一场错过的会议或一位困惑的客户。一次性修复底层数据源，就能从此消除这一整类错误。该端点的文档见 /docs/timezone-lookup/。