应用场景

安排网络研讨会,为每位参会者显示正确的时间

“周四美国东部时间下午 2 点与我们相见”对于本来就习惯用东部时间思考的参会者来说很精确,对其他人来说却是一场猜谜游戏。一家为国际受众定期举办网络研讨会的 B2B 软件公司发现,相当一部分缺席和迟到都可以追溯到参会者把时区换算算错了,或者根本没有换算,以为邀请指的是他们自己当地的下午 2 点。

该公司的注册表单本来就会收集电子邮件地址,并且出于排期目的收集一个大致位置:要么由注册者直接填写,要么在其注册时根据其 IP 地址推断,通过 /v1/ip 解析为坐标以及国家和城市。这些坐标再传给 /v1/timezone,后者返回注册者所在位置的 IANA 时区名称,使公司能够可靠地计算出这位参会者参加网络研讨会的正确本地时间,而不必依赖参会者自己换算。

此后的每封确认邮件都会把网络研讨会时间显示两次:一次使用主讲人自己的时区以保持一致,另一次专门按该参会者解析得到的时区计算,用通俗的语言写明,而不是给出一个还需要读者进一步计算的偏移量。同样的双重显示也延续到了确认邮件所附的日历邀请中,因此参会者把活动添加到自己的日历时,会自动看到它落在正确的本地时刻,无需信任手动换算。

由于网络研讨会通常提前数周安排,有时会跨越某个地区的夏令时切换而另一个地区不切换,公司依赖时区查询的能力,按网络研讨会未来的具体日期计算正确的偏移,而不是发送邀请当天生效的偏移。存储 IANA 名称而不是固定偏移,意味着这一切始终保持正确,公司里无需有人跟踪哪些地区即将调整时钟,再手动修改邀请。

可衡量的结果是,要求确认即将举行的会议实际本地时间的支持和销售邮件数量明显减少。在此之前,这种员工时间上虽小却反复出现的成本,一直被视为举办国际网络研讨会不可避免的一部分。出席率也略有提高,不过公司谨慎地指出,出席率提升很可能来自多种因素,更清晰的时区显示只是其中之一,而不是唯一的解释。

调用量很小且可预测,每位注册者在注册时查询一次。即使对于频繁举办网络研讨会的公司,这样的工作量也从未接近每日免费配额,因为任何单场活动的注册量都很少达到让请求成本成为重要考虑因素的规模。

为每位参会者单独给出正确的会议时间,而不是让每个人自己换算,能消除一个虽小却真实存在的摩擦,哪怕只是按时参加一个预定的通话这样简单的事。两个端点的文档分别位于 /docs/ipv4-lookup/ 和 /docs/timezone-lookup/。