刚刚给服务器配时区突然意识到，中国标准时间（ China Standard Time ），和美国中部标准时间（ Central Standard Time ）都是 CST ，这难道不会有歧义吗？

一般会有时区吧

UTC 用得比较多吧，中国 UTC+8

用 Aisa/Shanghai 啊，或者用 PRC

这个是最好的

Wikipedia:时区通常都用字母缩写形式来表示，例如“EST 、WST 、CST”等。但是它们并不是 ISO 8601 标准的一部分，不应单独用它们作为时区的标识。一些缩写可能意义模糊，例如“BST”应当是英国夏令时，但在 1968 年到 1971 年间被重命名为“英国标准时”，这只是因为立法者不愿称其为中欧时间。在该法案中还确认英国的标准时间仍然为格林威治标准时。Ref: zh.wikipedia.org/wiki/时区

代码里我选择 UTC+8每次都想不起来 beijing 到底需不需要大写有没有下划线（刚看了一眼 HongKong 有下划线）

现在 hongkong 我也不敢用了, 因为每次都会想到在后面加上 doll

对，而且最近刚好因为这事，配合 chrome 的一个 bug 出过问题 bugs.chromium.org/p/chromium/issues/detail?id=1473422chrome 在某次更改中打破了原有识别时区的逻辑，导致 fallback 到通过类似 cst 这样的三字母去解析时区，然后因为冲突和一些映射方面的问题，导致时区错误，或者获取到 undefined 的问题

我看了一下自己以前写的代码，确实很离谱。if (timeadj == "cst") localadj = -( 6 3600 ); // Central Standard Time (North America)if (timeadj == "cst") localadj = ( 9 3600 +6030 ); // Central Standard Time (Australia)if (timeadj == "cst") localadj = (10 3600 +6030 ); // Central Summer Time (Australia)if (timeadj == "cst") localadj = -( 5 3600 ); // Cuba Standard Timeif (timeadj == "cst") localadj = ( 8 *3600 ); // China Standard Time

主要看偏移量，看缩写有可能是算出来的不准

CST 全球至少有 4 个国家地区用的缩写，在哪看到过，忘了，具体还得 +08：00

真正弄时区我觉得应该用 Asia/Shanghai 这类的地区，操作系统提供选择的也是地区因为有的地区有夏令时，比如现在我们早晨 10 点的时候，加州那边是前一天晚上 6 点；然后上个月的时候，我们的早晨 10 点是加州那边的晚上 7 点然后不同年份，同一地区的时区可能不同，我们之前也试行过几年夏令时

北京时间，China Standard Time澳洲中部时间，Central Standard Time (Australia)北美中部时区，Central Standard Time (North America)古巴标准时间，Cuba Standard Time ，参见北美东部时区

我感觉“2023-03-07T10:30:00Z”这种格式的时间最好用，客户端拿到后会解释为本地时区的时间

我一直用的 Asia/Singapore (CST, +0800)

偏移量也不一定准，你考虑下夏时令，还有其实各国也可能随时更新它的时区，因此需要一个动态的数据

你是把你的输入法训练出来了吗？😂

还是得看城市，因为 UTC +几并不能代表夏令时/冬令时

中情局我特么原先一直以为是中国的。。。

Javaer 可太熟了：Java 的 CST 代表美国中部标准时间（ Central Standard Time ），MySQL 的 CST 代表中国标准时间（ China Standard Time ），两者相差 13~14 小时

确实会有歧义，强烈不建议使用。我经常上的一个学术讲座网站，里面显示就有 cst 的问题，以至于我还得再根据活动地点来判断到底是中是美。

之前同事就因为两个 CST 踩坑了

卧槽，重来没注意过还有这事，不过基本上如果服务器/数据库拿过来我自己配置都是 Asia/Shanghai 或者 UTC+8 ，其他同事配置的没准就有这个问题。

时区存储要遵循 tzdb 和 rfc6557 ，用 tz database 的 identifier 表示（比如 Asia/Shanghai ），不会有歧义。否则如果用固定的 offset ，很容易遇到前边说的冬令时/夏令时问题。。时间本身用 UTC 时间戳就好，配合时区渲染。。

踩过这个坑，美国客户发的会议邀请，上面写的是 cst 时间，然后就放了他们鸽子...

前段时间 Chrome 还因为这个问题产生了一个 Bug：可以看看这篇文章《 Chrome 获取时区 P0 bug 的技术分析和个人感想》 zhuanlan.zhihu.com/p/663583953

但是你给服务器分配的时候应该写的不是 CST 而是 Asia/Shanghai 啊，你咋就能联想到 Central Standard Time 呢？？

不要用 UTC+8 来代表中国时区中国时区并不“总是”UTC+8

UTC 偏移值比夏令时冬令时准确太多，不用隔几年回来看还要去 Google 下当年是哪天切换的冬夏令时。至于日常使用，直接把 UTC 偏移值改了就行

现在还是优先用 IANA 时区标签比较好，Asia/Shanghai 这样，虽然不是什么权威，但基本是比较好的事实标准

UTC+N 表示的是自然时区，和 CST Asia/Shanghai 这种表示对法令时区不一样。不是准确不准确的问题，这根本就不是一种东西。

涉及到 Local 的时区，中国时间唯一的标准就是 Asia/Shanghai 。CST 这种国家自己定义，而非国际协会/传统定义的缩写，就是大坑。

这个标准确实不错，唯一的遗憾就是它好像不是那么权威

也不能这么说，这个数据库还是以城市为基准，只能说今天用的最多的是上海，翻翻数据库历史上还是有好多个子标签的

这。。好坑

其实中国时区用 HKT 也没歧义，我就换成了这个

不是同一个东西，但是用 UTC 偏移值能精准地表示一个时间。影响 Local Time 的因素太多，不便于不同 Local Time 的人交换时间日期

IANA 还不算权威吗？

配 Shanghai ，默认的时间格式化出来的是 CST

HKT 在日本占领那几年是几啊？

精确的表示一个时刻应该用“UTC 本身”而不是“UTC 偏移”

我知道格式化出来是 CST但人家没说这个输出可以进行逆格式化操作吧？

时区配 Shanghai ，locale 选 zh_CN 的话，应该不是 CST 而是“中国标准时间”六个字吧

可以举一个反例吗

歧义就是你在服务器上打 date ，出来的 CST 不知道是啥

我刚才试了试，locale zh_CN 的情况下，几年几月几日，星期几都是汉字，但后面确实是 CST 并不是“中国标准时间”这 tmd 确实不知道他在说什么

查了下 中国三十多年前用过夏令时，到 92 年就不用了。

说到 local time 的奇怪事情，就想起了当年左耳朵耗子的一篇文章《你确信你了解时间吗？》 coolshell.cn/articles/5075.html

Asia

＃25 hhhhh 这实在是好离谱...

CST 表示中部时间的时候，只有美国人和美国人交流才会这么说美国之外，没人明白啥 PST ，EST ，CST 这些玩意儿

POSIX 的 TZ 环境变量的偏转量来表示：＃ export TZ=CST-8 && dateFri 17 Nov 2023 03:40:42 PM CST＃ export TZ=CST+6 && dateFri 17 Nov 2023 01:40:48 AM CST也可以用 IANA 时区名称，如：America/New_York 等，当然也可以用 ISO8601 的 UTC 偏转量 UTC+08:00/UTC-06:00

中部时间 CST 比 UTC 多一个好处，就是自带冬令时夏令时属性… 中部时间的 UTC 在冬天夏天是不一样的。

CST 目前情况下一定是 UTC -6 吧，夏令时会用 CDT (UTC -5)当然日常使用懒得想是冬夏就直接 PT CT ET 了

你说的对，我记错了... 很多系统里确实有 CT 这个选项，自备了时区~

在大多数情况下还是建议使用 IANA 时区名称来表示时区，Unix 时间戳来存储时间，因为三字母时区名会冲突，同时一个国家/地区的 UTC 偏移可能会因为各种原因变动，只存储 UTC 偏移是不够的 flyhigher.top/develop/2482.html当然也看见过 MySQL 在设置为 IANA 时区的情况下，拒接解析夏令时切换时的“消失的时间”字符串为时间戳，没有 fallback 直接报错的问题，所以具体用什么怎么做还是要看具体需求

还是不用好，太容易搞错了