根据访客位置显示正确的营业时间

“我们营业到晚上 6 点”只有在读到它的访客知道您指的是哪个时区的 6 点时才有用。与您的企业处于不同时区的访客，需要用他们自己的本地时间而不是您的时间来完成这个比较。

获取访客的时区

一次 IP 查询就会直接返回 timezone 字段，无需额外调用即可得到您需要的信息。

GET /v1/ip?ip=203.0.113.44

{
  "status": "ok",
  "ip": "203.0.113.44",
  "version": 4,
  "found": true,
  "country": "Japan",
  "country_code": "JP",
  "region": "Tokyo",
  "city": "Tokyo",
  "postcode": "100-0001",
  "lat": 35.6762,
  "lon": 139.6503,
  "timezone": "Asia/Tokyo",
  "asn": 2345,
  "org": "Example Telecom"
}

与您的营业时间进行比较

使用刚刚获取的时区标识符，把按您企业自身时区存储的营业时间转换到访客的时区，然后与访客当前的本地时间进行比较，以决定显示“正在营业”还是“已打烊”，同时注明该状态所依据的本地时间。

第二个例子：拥有多个门店的企业

在不同城市设有门店的企业，应当按照每个门店自己存储的时区查找其公布的营业时间，然后分别与访客的时区进行比较，而不是假设一套营业时间适用于所有地方。当访客在同一页面上比较两个门店时，这一点尤为重要，因为如果它们位于不同时区，或者遵循不同的夏令时规则，在完全相同的时刻，可能一个显示营业而另一个显示打烊。

明确说明您指的是哪个时区

与其悄悄地转换并寄希望于访客能理解，不如把两部分信息都清楚地显示出来，比如“当前已打烊。按您的时间（Asia/Tokyo）上午 9 点开门。”明确说明可以避免混淆，尤其是当企业跨越一条一侧实行夏令时、另一侧不实行的时区边界时。

需要避免的常见错误

不要只计算一次营业或打烊的比较结果，然后在访客会话的剩余时间里缓存这个布尔值。在下午 5:55 做出的比较会显示“正在营业”，而如果底层的营业状态被缓存而不是重新计算，到下午 6:05 时它仍会保持错误。请缓存访客的时区标识符，因为它在一个会话中确实是稳定的，但在每次渲染时都重新计算实际的营业或打烊比较。

一个边界情况：不实行夏令时的时区

有些地区全年保持固定偏移，而相邻地区每年切换两次，这意味着两个时区之间的差值在一年中并不是恒定的。如果您的比较逻辑硬编码了以小时计的偏移，而不是基于时区标识符并让日期库处理转换，那么恰恰在夏令时切换前后的那几周，它就会失去同步。

缓存时区，而不是营业状态

访客的时区标识符在一个会话中是稳定的，值得缓存。而企业当前是否营业会在一天中不断变化，因此请在渲染时使用缓存的时区重新计算这一比较，而不是缓存营业或打烊状态本身。

检查过去或未来的特定时刻

如果您需要知道某个特定时刻（而不是现在）的偏移是多少或将是多少，例如确认昨天下的一笔订单在客户所在时区实际是几点，/v1/timezone 接受一个可选的 time 参数（Unix 时间戳），正是用于这类历史或未来的检查。

请求成本

每个新访客会话进行一次 IP 查询就足以支持这一功能。也就是说，一次请求在整个访问期间被缓存，即使是繁忙的网店，也能稳稳保持在每个密钥包含的每天 2,500 次免费请求之内。

为全球受众正确显示“正在营业”，只需一次查询加一个简单的时间比较，并不是一项复杂的功能。IPv4 查询文档列出了完整的响应结构。