在结账前核对地址与所填邮政编码是否一致
订单表单上邮政编码与城市不一致，看起来只是个小笔误，直到包裹被送到国内完全不同的地方。
在多地区支持队列中显示正确的当地时间
一位在某个办公室的支持人员看到一张在“上午 3:47 点”提交的工单时，完全不知道这对客户来说是深夜还是工作日的正中。当公司的客户遍布多个大洲时，不附时区的时间戳几乎毫无用处，一家在三个地区设有支持台的软件公司就经常遇到这个问题。支持人员会打开工单，查看客户的账单国家，然后手动查询该国家是早于还是晚于自己，而出错的频率高到“抱歉这么早打扰您”成了办公室里的一个老梗。
公司用工单进入时发起的两次调用取代了这种猜测。首先，/v1/ip 读取访客的 IP 地址，返回国家、地区、城市和坐标，同一响应中还直接包含一个时区字段。对大多数工单来说，仅这个字段就已足够。对于少数需要更高精度的情况，例如安排回电，会把这次查询得到的坐标传给 /v1/timezone，它返回该确切地点的 IANA 时区名称和当前 UTC 偏移，还可以选择按特定时刻而不是当前时间计算。
IANA 名称比听上去更重要。原始的 UTC 偏移会随着夏令时规则而变化，而这些规则因国家而异，有时在一个国家内部也因地区而异，因此在客户记录中存储“UTC+2”，每年会悄悄出错两次。改为存储“Europe/Warsaw”，则意味着无论工单或回电安排在哪一天，偏移总能被正确计算，因为驱动它的时区数据库会随时跟踪这些规则变化。
看得见的变化是每张工单顶部多了一小行：客户此刻的本地时间，就在其姓名旁边。支持人员不再问“您那边是不是很晚了”，而是开始用准确的“下午好”开头。工单分配也得到了改善，因为队列可以按照哪些客户当前正处于其所在地区的工作时间内来排序，而不是按照哪个支持台碰巧有人值班。
这一切都不需要手动维护一个国家到时区的映射数据库。公司以前就是这样东拼西凑的，而每当客户的 IP 解析到一个跨越多个时区的大国时，这种方法就会失效。直接根据坐标读取时区，消除了这一整类错误。
调用量很小，每张新工单查询一次，远在公司密钥所含的每天 2,500 次免费请求之内。单是支持工具从未接近需要预付额度的程度，不过同一个密钥还覆盖了产品中其他确实需要预付额度的部分。
时区处理是那种只有出错时客户才会注意到的细节之一。在每张工单的后台悄无声息地把它做对，是一个小修复，却能对支持团队给人的印象产生超乎寻常的影响。两个端点的文档分别位于 /docs/ipv4-lookup/ 和 /docs/timezone-lookup/。