永不过期的 API 密钥带来的问题
一个多年前签发、从未轮换、至今仍然有效的密钥并不是一种便利。它是一个多年来没有人真正检查过的隐患。
开放的时区数据不应该是付费功能
IANA 时区数据库是公开的。几十年来它一直以公开的方式维护，记录各国政府做出的每一次偏移变更、夏令时规则调整和边界重划。互联网上几乎所有正规的时区查询，包括我们的在内，都建立在同一个公开数据集之上。因此，当一个 API 在已经收取的地理编码费用之外，专门为时区查询另收一笔高价时，值得问一问这笔溢价究竟买的是什么。
有时答案是正当的：随着时区边界变化，保持坐标与时区边界之间映射准确所花费的工程时间，以及大规模提供查询服务的基础设施。这是实实在在的工作，也需要成本。不那么正当的是，把时区数据当作一条单独的产品线，设立自己的价格档位，定价远高于单次查询的边际成本，只因为它可以被捆绑进客户本来就需要的工作流程中，客户也不太可能为它单独货比三家。
我们不把时区拆分为高级附加功能。它是多个端点之一，与其他所有端点价格相同：由每日免费配额覆盖，超出之后与其他所有端点一样按每次请求 €0.0001 计费，或包含在同样的 €50 Unlimited 密钥中。没有单独的时区档位，询问某组坐标当地是几点也没有任何加价。
时区查询比它平淡无奇的名字所暗示的更重要。排程系统、日志管道、预订平台，以及任何需要向用户显示正确当地时间的应用，都依赖于把这件事做对。一旦出错，会议邀请就会差一个小时，日志时间戳会误导调查，配送时间窗会承诺错误的当地钟点。这恰恰是那种应该便宜而平淡的查询，而不是在账单上突然跳出一大笔的项目。
时区查询在别处被当作高级功能的部分原因是，夏令时切换和边界变化让底层数据看起来比静态的国家代码更复杂。这确实是维护起来很繁琐的数据。但维护繁琐并不等于每次请求的服务成本高昂，定价应当反映后者，而不是前者的复杂程度。
对时区数据收取溢价还会在 API 设计层面造成不良激励：服务商不再愿意直接开放它，而是想把它包进更大、更贵的套装里，理由是一个无人能单独比价的功能更容易加价。我们认为相反的做法更能赢得信任。让端点简单明了，与其他一切同价，让开发者按应用所需的频率使用它，而不必在心里盘算这一次查询是不是昂贵的那种。