这是一个创建于 380 天前的主题，其中的信息可能已经有所发展或是发生改变。
刚刚给服务器配时区突然意识到，中国标准时间（ China Standard Time ），和美国中部标准时间（ Central Standard Time ）都是 CST ，这难道不会有歧义吗？
 |
1
cocogovern 2023-11-17 09:32:51 +08:00
一般会有时区吧
|
 |
2
ltyj2003 2023-11-17 09:34:38 +08:00 via Android
UTC 用得比较多吧，中国 UTC+8
|
 |
3
CodeCodeStudy 2023-11-17 09:35:11 +08:00
用 Aisa/Shanghai 啊，或者用 PRC
|
 |
4
arnoldxiao 2023-11-17 09:36:42 +08:00
@ltyj2003 这个是最好的
|
 |
5
mschultz 2023-11-17 09:38:12 +08:00  2
Wikipedia:
时区通常都用字母缩写形式来表示，例如“EST 、WST 、CST”等。但是它们并不是 ISO 8601 标准的一部分，不应单独用它们作为时区的标识。一些缩写可能意义模糊，例如“BST”应当是英国夏令时，但在 1968 年到 1971 年间被重命名为“英国标准时”，这只是因为立法者不愿称其为中欧时间。在该法案中还确认英国的标准时间仍然为格林威治标准时。 Ref: https://zh.wikipedia.org/wiki/时区 |
 |
6
chendy 2023-11-17 09:38:58 +08:00
代码里我选择 UTC+8
每次都想不起来 beijing 到底需不需要大写有没有下划线（刚看了一眼 HongKong 有下划线） |
 |
8
codehz 2023-11-17 09:50:40 +08:00 via iPhone
对，而且最近刚好因为这事，配合 chrome 的一个 bug 出过问题
https://bugs.chromium.org/p/chromium/issues/detail?id=1473422 chrome 在某次更改中打破了原有识别时区的逻辑，导致 fallback 到通过类似 cst 这样的三字母去解析时区，然后因为冲突和一些映射方面的问题，导致时区错误，或者获取到 undefined 的问题 |
 |
9
tool2d 2023-11-17 09:51:43 +08:00
我看了一下自己以前写的代码，确实很离谱。
if (timeadj == "cst") localadj = -( 6 *3600 ); // Central Standard Time (North America) if (timeadj == "cst") localadj = ( 9 *3600 +60*30 ); // Central Standard Time (Australia) if (timeadj == "cst") localadj = (10 *3600 +60*30 ); // Central Summer Time (Australia) if (timeadj == "cst") localadj = -( 5 *3600 ); // Cuba Standard Time if (timeadj == "cst") localadj = ( 8 *3600 ); // China Standard Time |
 |
10
vuevue 2023-11-17 09:54:52 +08:00 via Android
主要看偏移量，看缩写有可能是算出来的不准
|
 |
11
rickiey 2023-11-17 10:13:23 +08:00 1
CST 全球至少有 4 个国家地区用的缩写，在哪看到过，忘了，具体还得 +08：00
|
 |
12
hahastudio 2023-11-17 10:20:51 +08:00
真正弄时区我觉得应该用 Asia/Shanghai 这类的地区，操作系统提供选择的也是地区
因为有的地区有夏令时，比如现在我们早晨 10 点的时候，加州那边是前一天晚上 6 点；然后上个月的时候，我们的早晨 10 点是加州那边的晚上 7 点 然后不同年份，同一地区的时区可能不同，我们之前也试行过几年夏令时 |
|
13
hahastudio 2023-11-17 10:22:29 +08:00 2
@rickiey
北京时间，China Standard Time 澳洲中部时间，Central Standard Time (Australia) 北美中部时区，Central Standard Time (North America) 古巴标准时间，Cuba Standard Time ，参见北美东部时区 |
 |
14
7inFen 2023-11-17 10:32:00 +08:00
我感觉“2023-03-07T10:30:00Z”这种格式的时间最好用，客户端拿到后会解释为本地时区的时间
|
 |
15
mingwiki 2023-11-17 10:46:44 +08:00
我一直用的 Asia/Singapore (CST, +0800)
|
 |
18
nzynzynzy 2023-11-17 11:10:23 +08:00
还是得看城市，因为 UTC +几并不能代表夏令时/冬令时
|
 |
19
vishun 2023-11-17 11:27:24 +08:00 3
中情局我特么原先一直以为是中国的。。。
|
 |
20
sherlockwoo 2023-11-17 11:38:28 +08:00
Javaer 可太熟了：
Java 的 CST 代表美国中部标准时间（ Central Standard Time ），MySQL 的 CST 代表中国标准时间（ China Standard Time ），两者相差 13~14 小时 |
 |
21
shakoon 2023-11-17 11:42:24 +08:00
确实会有歧义，强烈不建议使用。我经常上的一个学术讲座网站，里面显示就有 cst 的问题，以至于我还得再根据活动地点来判断到底是中是美。
|
 |
22
Oktfolio 2023-11-17 11:46:37 +08:00
之前同事就因为两个 CST 踩坑了
|
 |
23
zliea 2023-11-17 11:53:40 +08:00
卧槽，重来没注意过还有这事，不过基本上如果服务器/数据库拿过来我自己配置都是 Asia/Shanghai 或者 UTC+8 ，其他同事配置的没准就有这个问题。
|
 |
24
Senorsen 2023-11-17 12:08:23 +08:00
时区存储要遵循 tzdb 和 rfc6557 ，用 tz database 的 identifier 表示（比如 Asia/Shanghai ），不会有歧义。否则如果用固定的 offset ，很容易遇到前边说的冬令时/夏令时问题。。
时间本身用 UTC 时间戳就好，配合时区渲染。。 |
 |
25
sparkle2015 2023-11-17 12:12:03 +08:00
踩过这个坑，美国客户发的会议邀请，上面写的是 cst 时间，然后就放了他们鸽子...
|
 |
26
mw2c 2023-11-17 12:31:38 +08:00
前段时间 Chrome 还因为这个问题产生了一个 Bug：可以看看这篇文章《 Chrome 获取时区 P0 bug 的技术分析和个人感想》 https://zhuanlan.zhihu.com/p/663583953
|
 |
27
julyclyde 2023-11-17 12:43:24 +08:00
但是你给服务器分配的时候应该写的不是 CST 而是 Asia/Shanghai 啊，你咋就能联想到 Central Standard Time 呢？？
|
|
28
julyclyde 2023-11-17 12:43:52 +08:00 1
不要用 UTC+8 来代表中国时区
中国时区并不“总是”UTC+8 |
 |
29
xmumiffy 2023-11-17 12:44:15 +08:00 via Android
UTC 偏移值比夏令时冬令时准确太多，不用隔几年回来看还要去 Google 下当年是哪天切换的冬夏令时。至于日常使用，直接把 UTC 偏移值改了就行
|
 |
30
iseki 2023-11-17 12:47:59 +08:00 via Android
现在还是优先用 IANA 时区标签比较好，Asia/Shanghai 这样，虽然不是什么权威，但基本是比较好的事实标准
|
|
31
iseki 2023-11-17 12:48:59 +08:00 via Android
@xmumiffy UTC+N 表示的是自然时区，和 CST Asia/Shanghai 这种表示对法令时区不一样。不是准确不准确的问题，这根本就不是一种东西。
|
 |
32
nothingistrue 2023-11-17 12:54:09 +08:00
涉及到 Local 的时区，中国时间唯一的标准就是 Asia/Shanghai 。CST 这种国家自己定义，而非国际协会/传统定义的缩写，就是大坑。
|
|
33
iseki 2023-11-17 12:55:40 +08:00 via Android
@hahastudio 这个标准确实不错，唯一的遗憾就是它好像不是那么权威
|
|
34
iseki 2023-11-17 12:57:02 +08:00 via Android
@nothingistrue 也不能这么说，这个数据库还是以城市为基准，只能说今天用的最多的是上海，翻翻数据库历史上还是有好多个子标签的
|
 |
35
enchilada2020 2023-11-17 13:20:29 +08:00 via Android
@sparkle2015 这。。好坑
|
|
36
xmumiffy 2023-11-17 13:21:29 +08:00 via Android
其实中国时区用 HKT 也没歧义，我就换成了这个
|
|
37
xmumiffy 2023-11-17 13:24:03 +08:00 via Android
@iseki 不是同一个东西，但是用 UTC 偏移值能精准地表示一个时间。
影响 Local Time 的因素太多，不便于不同 Local Time 的人交换时间日期 |
|
43
julyclyde 2023-11-17 13:28:50 +08:00
@xmumiffy 时区配 Shanghai ，locale 选 zh_CN 的话，应该不是 CST 而是“中国标准时间”六个字吧
|
 |
44
whileFalse 2023-11-17 13:30:40 +08:00 via Android
@julyclyde 可以举一个反例吗
|
|
46
julyclyde 2023-11-17 13:36:35 +08:00
|
|
47
whileFalse 2023-11-17 13:39:45 +08:00 via Android
查了下 中国三十多年前用过夏令时，到 92 年就不用了。
|
|
48
hahastudio 2023-11-17 13:41:49 +08:00
说到 local time 的奇怪事情，就想起了当年左耳朵耗子的一篇文章《你确信你了解时间吗？》
https://coolshell.cn/articles/5075.html |
 |
49
bugmakerxs 2023-11-17 14:09:06 +08:00
@CodeCodeStudy Asia
|
 |
50
AKAUP 2023-11-17 14:11:11 +08:00
@sparkle2015 #25 hhhhh 这实在是好离谱...
|
 |
51
dayeye2006199 2023-11-17 14:27:50 +08:00
CST 表示中部时间的时候，只有美国人和美国人交流才会这么说
美国之外，没人明白啥 PST ，EST ，CST 这些玩意儿 |
 |
52
gesse 2023-11-17 15:44:15 +08:00
POSIX 的 TZ 环境变量的偏转量来表示：
# export TZ=CST-8 && date Fri 17 Nov 2023 03:40:42 PM CST # export TZ=CST+6 && date Fri 17 Nov 2023 01:40:48 AM CST 也可以用 IANA 时区名称，如：America/New_York 等， 当然也可以用 ISO8601 的 UTC 偏转量 UTC+08:00/UTC-06:00 |
 |
53
Jiceburger 2023-11-17 15:44:26 +08:00 via Android
中部时间 CST 比 UTC 多一个好处，就是自带冬令时夏令时属性… 中部时间的 UTC 在冬天夏天是不一样的。
|
 |
54
Biggoldfish 2023-11-17 15:49:25 +08:00
|
|
55
Jiceburger 2023-11-17 16:06:15 +08:00
@Biggoldfish 你说的对，我记错了... 很多系统里确实有 CT 这个选项，自备了时区~
|
 |
56
AxtonYao 2023-11-17 16:33:54 +08:00 via iPhone 1
在大多数情况下还是建议使用 IANA 时区名称来表示时区，Unix 时间戳来存储时间，因为三字母时区名会冲突，同时一个国家/地区的 UTC 偏移可能会因为各种原因变动，只存储 UTC 偏移是不够的
https://flyhigher.top/develop/2482.html 当然也看见过 MySQL 在设置为 IANA 时区的情况下，拒接解析夏令时切换时的“消失的时间”字符串为时间戳，没有 fallback 直接报错的问题，所以具体用什么怎么做还是要看具体需求 |
 |
57
chapiom 2023-11-17 17:01:29 +08:00
@whileFalse 还是不用好，太容易搞错了
|
 |
58
MuSeCanYang 318 天前
我们用 BJT ．．．．
|
Select Language