为支持控制台添加本地时间时钟小组件

支持人员在决定是否立即给客户打电话时，了解客户所在地的实际时间会很有帮助，而不是办公室的时间。

如果您已存有收货地址或账单地址，先对其进行一次地理编码获取坐标，再把这些坐标传给 /v1/timezone。如果您只有客户上次访问时的 IP 地址，/v1/ip 端点会直接返回 timezone 字段，无需另行查询。

GET /v1/timezone?lat=35.6762&lon=139.6503

{
  "status": "ok",
  "timezone": "Asia/Tokyo",
  "utc_offset": "+09:00",
  "abbreviation": "JST"
}

对于既没有地址也没有记录 IP 的潜在客户或工单，就没有可靠的坐标可用来查询时区，而根据电话国家代码或语言设置来猜测，并不是这个端点能替您做的事。这种情况下，请直接询问时区或大致位置，而不要显示一个基于猜测、很可能相差好几个小时的时钟。

将时区标识符存储在客户记录中，然后在每次呈现控制台时据此计算当前本地时间，而不是存储一个在夏令时切换前后会过时的固定偏移量。由于网站没有客户端 JavaScript，请在页面加载时于服务器端呈现当前本地时间，并在每次页面请求时刷新，而不是在浏览器中实时走动。

客户所在位置的时区标识符不会每天变化，因此请在首次记录地址或 IP 时查询一次并存储该标识符，而不是每次加载控制台都调用 API。这样该功能总共只需少量请求，而不是每次页面浏览一次；如果支持团队每天要多次打开控制台，这一点就很重要。

用今天的时区查询结果而不是交互本身的时间戳，为过去的支持交互重新计算偏移量，可能会在夏令时切换前后显示错误的小时。如果控制台需要显示客户提交某个过去工单时的当地时间，请通过 time 参数传入该工单自己的时间戳，而不要依赖当前的偏移量。

即使不缓存标识符，每次查询也只是一次请求，因此任何规模合理的支持团队都能轻松控制在每个密钥附带的每天 2,500 次免费请求之内，或无密钥时单个地址享有的同等配额之内。

如果客户存档的地址发生变化，请同时刷新存储的时区标识符，而不要让过时的标识符一直附在记录上。搬迁后的客户如果仍使用旧的时区标识符，在记录更新之前会一直显示错误的本地时间，而且这是悄无声息的，因为旧的查询本身不会失败或报错。

工单旁的本地时间时钟只是一个小小的补充，却能让支持人员免于在每次通话前心算时区差异。时区查询文档完整介绍了该请求。

更多指南