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