看懂一份时区列表，并且别用错
时区列表看着像参考资料，直到你真的要选一个。这时候问题才来：为什么同一个偏移量下面有三条记录？时区标识符到底是干什么用的？接口要的又是哪一个？
标识符不是偏移量
这里的每一条都是 IANA 时区标识符，形式为「区域/地点」——Europe/Berlin、America/Argentina/Buenos_Aires、Asia/Kolkata。标识符命名的是一个地区和一套规则；旁边那个数字，比如 UTC+02:00，只是这套规则今天算出来的结果。
一旦某个时区发生变化，这个区别立刻变得重要。Europe/Berlin 多年来一直是冬季 UTC+01:00、夏季 UTC+02:00，而标识符一次都没变过。时间戳和标识符一起存，含义永远明确；只存一个裸偏移量，就不是了。
缩写会骗人
CST 可以是北美的中部标准时间，可以是北京的中国标准时间，也可以是哈瓦那的古巴标准时间。IST 可以是印度、爱尔兰或以色列。BST 可以是英国夏令时，也可以是孟加拉标准时间。
缩写不唯一、没有统一标准，也不属于标识符体系。按缩写排序的表格，会把相差十一个小时的城市排在相邻两行——排期事故往往就是这么来的。
Etc/GMT 的符号陷阱
Etc/GMT+5 和 Etc/GMT-5 这类固定偏移时区，符号和直觉是反的：Etc/GMT+5 表示比 UTC 慢五小时，也就是 UTC−05:00。这个约定来自 POSIX 的 TZ 变量，为了兼容而保留，不是为了好懂。
如果只需要一个恒定偏移，直接写偏移量，别用时区名。只有当上下游明确要求 IANA 字符串时，才去碰 Etc/GMT 系列。
偏移相同，规则不同
两个城市可以全年共享同一个偏移量，却仍然需要不同的标识符，因为它们背后的规则不一样。Asia/Shanghai 和 Asia/Singapore 都在 UTC+08:00 且不实行夏令时，但它们依旧是两条独立记录，各有各的历史。
这正是「看起来合理的捷径」翻车的地方。用错标识符搭出来的日历，今天的时刻是对的，五年前的日期却是错的——而且往往要等到有人去核对历史记录才会发现。
搜索与筛选
搜索框匹配的是标识符，所以只要城市名出现在标识符里就能搜到：搜「Shanghai」得到 Asia/Shanghai，搜「Buenos」得到 America/Argentina/Buenos_Aires。国家名和偏移量搜不到。
区域按钮把列表收窄到单个一级区域——America、Europe、Asia、Africa、Australia、Pacific、Atlantic、Indian、Arctic、Antarctica。最近的选择保存在浏览器本地，不会发往任何服务器。