在技术文档和日常交流中，人们习惯用 CST、EST、PST 这类三个字母的缩写表示时区。但这些缩写存在严重的歧义，是全球时间处理中最常见的坑之一。

一、CST 到底是谁

CST 至少可以指三件完全不同的事：

China Standard Time，北京时间，UTC+8；
Central Standard Time，北美中部标准时间，UTC-6；
Cuba Standard Time，古巴标准时间，UTC-5。

也就是说，看到 CST，你无法判断它到底是 UTC+8 还是 UTC-6，两者相差 14 小时。在中文语境里写 CST 指中国标准时间，放到国际项目中就会被北美同事理解成完全不同的东西。

二、其他容易混淆的缩写

EST 可指北美东部标准时间（UTC-5），也可指澳大利亚东部标准时间（UTC+10），相差 15 小时。
IST 可指印度标准时间（UTC+5:30）、爱尔兰标准时间（UTC+1）或以色列标准时间（UTC+2）。
BST 可指英国夏令时（UTC+1），也可指孟加拉国标准时间（UTC+6）。
AEST 与 EST 在澳大利亚语境下常被混写，但前者是明确的 UTC+10。

三、"GMT+8"这种写法的问题

把时区写成 GMT+8 或 UTC+8，虽然明确了偏移量，但丢失了地理区域信息，因此无法处理夏令时。伦敦冬季是 UTC+0、夏季是 UTC+1，如果系统里固定存 GMT+0，夏季就会算错一小时。同时，某些地区历史上多次调整时区，用固定偏移量无法还原历史时间的正确值。

四、正确写法是什么

优先使用 IANA 时区标识符，格式为"区域/城市"：

北京时间写作 Asia/Shanghai，而不是 CST 或 GMT+8；
纽约写作 America/New_York，而不是 EST；
伦敦写作 Europe/London，而不是 GMT；
东京写作 Asia/Tokyo，巴黎写作 Europe/Paris。

这样写既无歧义，又能自动适配夏令时与历史规则变更。若必须写偏移量，请遵循 ISO 8601 格式，例如 2026-09-27T12:00:00+08:00，把偏移作为时间字符串的一部分，而不是单独存一个时区字段。

五、实用建议

数据库与日志统一用 UTC 或 Unix 时间戳存储，展示层再按用户所在 IANA 时区格式化，可以彻底绕开缩写歧义。需要确认某地当前实际时间与 UTC 偏移时，直接查看本站对应城市的时间页面最为可靠，页面会明确标注时区标识符、当前偏移与是否处于夏令时。