V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
villivateur
V2EX  ›  程序员

时区缩写的问题:中国标准时间和美国中部标准时间都是 CST?

  •  
  •   villivateur ·
    villivateur · 183 天前 · 4974 次点击
    这是一个创建于 183 天前的主题,其中的信息可能已经有所发展或是发生改变。

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

    58 条回复    2024-01-18 11:56:15 +08:00
    cocogovern
        1
    cocogovern  
       183 天前
    一般会有时区吧
    ltyj2003
        2
    ltyj2003  
       183 天前 via Android
    UTC 用得比较多吧,中国 UTC+8
    CodeCodeStudy
        3
    CodeCodeStudy  
       183 天前
    用 Aisa/Shanghai 啊,或者用 PRC
    arnoldxiao
        4
    arnoldxiao  
       183 天前
    @ltyj2003 这个是最好的
    mschultz
        5
    mschultz  
       183 天前   ❤️ 2
    Wikipedia:

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

    Ref: https://zh.wikipedia.org/wiki/时区
    chendy
        6
    chendy  
       183 天前
    代码里我选择 UTC+8
    每次都想不起来 beijing 到底需不需要大写有没有下划线(刚看了一眼 HongKong 有下划线)
    wu67
        7
    wu67  
       183 天前   ❤️ 10
    @chendy 现在 hongkong 我也不敢用了, 因为每次都会想到在后面加上 doll
    codehz
        8
    codehz  
       183 天前 via iPhone
    对,而且最近刚好因为这事,配合 chrome 的一个 bug 出过问题
    https://bugs.chromium.org/p/chromium/issues/detail?id=1473422
    chrome 在某次更改中打破了原有识别时区的逻辑,导致 fallback 到通过类似 cst 这样的三字母去解析时区,然后因为冲突和一些映射方面的问题,导致时区错误,或者获取到 undefined 的问题
    tool2d
        9
    tool2d  
       183 天前
    我看了一下自己以前写的代码,确实很离谱。

    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
    vuevue
        10
    vuevue  
       183 天前 via Android
    主要看偏移量,看缩写有可能是算出来的不准
    rickiey
        11
    rickiey  
       183 天前   ❤️ 1
    CST 全球至少有 4 个国家地区用的缩写,在哪看到过,忘了,具体还得 +08:00
    hahastudio
        12
    hahastudio  
       183 天前
    真正弄时区我觉得应该用 Asia/Shanghai 这类的地区,操作系统提供选择的也是地区
    因为有的地区有夏令时,比如现在我们早晨 10 点的时候,加州那边是前一天晚上 6 点;然后上个月的时候,我们的早晨 10 点是加州那边的晚上 7 点
    然后不同年份,同一地区的时区可能不同,我们之前也试行过几年夏令时
    hahastudio
        13
    hahastudio  
       183 天前   ❤️ 2
    @rickiey
    北京时间,China Standard Time
    澳洲中部时间,Central Standard Time (Australia)
    北美中部时区,Central Standard Time (North America)
    古巴标准时间,Cuba Standard Time ,参见北美东部时区
    7inFen
        14
    7inFen  
       183 天前
    我感觉“2023-03-07T10:30:00Z”这种格式的时间最好用,客户端拿到后会解释为本地时区的时间
    mingwiki
        15
    mingwiki  
       183 天前
    我一直用的 Asia/Singapore (CST, +0800)
    codehz
        16
    codehz  
       183 天前   ❤️ 1
    @vuevue 偏移量也不一定准,你考虑下夏时令,还有其实各国也可能随时更新它的时区,因此需要一个动态的数据
    gps949
        17
    gps949  
       183 天前
    @wu67 你是把你的输入法训练出来了吗?😂
    nzynzynzy
        18
    nzynzynzy  
       183 天前
    还是得看城市,因为 UTC +几并不能代表夏令时/冬令时
    vishun
        19
    vishun  
       183 天前   ❤️ 3
    中情局我特么原先一直以为是中国的。。。
    sherlockwoo
        20
    sherlockwoo  
       183 天前
    Javaer 可太熟了:
    Java 的 CST 代表美国中部标准时间( Central Standard Time ),MySQL 的 CST 代表中国标准时间( China Standard Time ),两者相差 13~14 小时
    shakoon
        21
    shakoon  
       183 天前
    确实会有歧义,强烈不建议使用。我经常上的一个学术讲座网站,里面显示就有 cst 的问题,以至于我还得再根据活动地点来判断到底是中是美。
    Oktfolio
        22
    Oktfolio  
       183 天前
    之前同事就因为两个 CST 踩坑了
    zliea
        23
    zliea  
       183 天前
    卧槽,重来没注意过还有这事,不过基本上如果服务器/数据库拿过来我自己配置都是 Asia/Shanghai 或者 UTC+8 ,其他同事配置的没准就有这个问题。
    Senorsen
        24
    Senorsen  
       183 天前
    时区存储要遵循 tzdb 和 rfc6557 ,用 tz database 的 identifier 表示(比如 Asia/Shanghai ),不会有歧义。否则如果用固定的 offset ,很容易遇到前边说的冬令时/夏令时问题。。
    时间本身用 UTC 时间戳就好,配合时区渲染。。
    sparkle2015
        25
    sparkle2015  
       183 天前
    踩过这个坑,美国客户发的会议邀请,上面写的是 cst 时间,然后就放了他们鸽子...
    mw2c
        26
    mw2c  
       183 天前
    前段时间 Chrome 还因为这个问题产生了一个 Bug:可以看看这篇文章《 Chrome 获取时区 P0 bug 的技术分析和个人感想》 https://zhuanlan.zhihu.com/p/663583953
    julyclyde
        27
    julyclyde  
       183 天前
    但是你给服务器分配的时候应该写的不是 CST 而是 Asia/Shanghai 啊,你咋就能联想到 Central Standard Time 呢??
    julyclyde
        28
    julyclyde  
       183 天前   ❤️ 1
    不要用 UTC+8 来代表中国时区
    中国时区并不“总是”UTC+8
    xmumiffy
        29
    xmumiffy  
       183 天前 via Android
    UTC 偏移值比夏令时冬令时准确太多,不用隔几年回来看还要去 Google 下当年是哪天切换的冬夏令时。至于日常使用,直接把 UTC 偏移值改了就行
    iseki
        30
    iseki  
       183 天前 via Android
    现在还是优先用 IANA 时区标签比较好,Asia/Shanghai 这样,虽然不是什么权威,但基本是比较好的事实标准
    iseki
        31
    iseki  
       183 天前 via Android
    @xmumiffy UTC+N 表示的是自然时区,和 CST Asia/Shanghai 这种表示对法令时区不一样。不是准确不准确的问题,这根本就不是一种东西。
    nothingistrue
        32
    nothingistrue  
       183 天前
    涉及到 Local 的时区,中国时间唯一的标准就是 Asia/Shanghai 。CST 这种国家自己定义,而非国际协会/传统定义的缩写,就是大坑。
    iseki
        33
    iseki  
       183 天前 via Android
    @hahastudio 这个标准确实不错,唯一的遗憾就是它好像不是那么权威
    iseki
        34
    iseki  
       183 天前 via Android
    @nothingistrue 也不能这么说,这个数据库还是以城市为基准,只能说今天用的最多的是上海,翻翻数据库历史上还是有好多个子标签的
    enchilada2020
        35
    enchilada2020  
       183 天前 via Android
    @sparkle2015 这。。好坑
    xmumiffy
        36
    xmumiffy  
       183 天前 via Android
    其实中国时区用 HKT 也没歧义,我就换成了这个
    xmumiffy
        37
    xmumiffy  
       183 天前 via Android
    @iseki 不是同一个东西,但是用 UTC 偏移值能精准地表示一个时间。
    影响 Local Time 的因素太多,不便于不同 Local Time 的人交换时间日期
    julyclyde
        38
    julyclyde  
       183 天前
    @iseki IANA 还不算权威吗?
    xmumiffy
        39
    xmumiffy  
       183 天前 via Android
    @julyclyde 配 Shanghai ,默认的时间格式化出来的是 CST
    julyclyde
        40
    julyclyde  
       183 天前
    @xmumiffy HKT 在日本占领那几年是几啊?
    julyclyde
        41
    julyclyde  
       183 天前
    @xmumiffy 精确的表示一个时刻应该用“UTC 本身”而不是“UTC 偏移”
    julyclyde
        42
    julyclyde  
       183 天前
    @xmumiffy 我知道格式化出来是 CST
    但人家没说这个输出可以进行逆格式化操作吧?
    julyclyde
        43
    julyclyde  
       183 天前
    @xmumiffy 时区配 Shanghai ,locale 选 zh_CN 的话,应该不是 CST 而是“中国标准时间”六个字吧
    whileFalse
        44
    whileFalse  
       183 天前 via Android
    @julyclyde 可以举一个反例吗
    xmumiffy
        45
    xmumiffy  
       183 天前 via Android
    @julyclyde 歧义就是你在服务器上打 date ,出来的 CST 不知道是啥
    julyclyde
        46
    julyclyde  
       183 天前
    @xmumiffy

    我刚才试了试,locale zh_CN 的情况下,几年几月几日,星期几都是汉字,但后面确实是 CST 并不是“中国标准时间”
    这 tmd 确实不知道他在说什么
    whileFalse
        47
    whileFalse  
       183 天前 via Android
    查了下 中国三十多年前用过夏令时,到 92 年就不用了。
    hahastudio
        48
    hahastudio  
       183 天前
    说到 local time 的奇怪事情,就想起了当年左耳朵耗子的一篇文章《你确信你了解时间吗?》
    https://coolshell.cn/articles/5075.html
    bugmakerxs
        49
    bugmakerxs  
       183 天前
    AKAUP
        50
    AKAUP  
       183 天前
    @sparkle2015 #25 hhhhh 这实在是好离谱...
    dayeye2006199
        51
    dayeye2006199  
       183 天前
    CST 表示中部时间的时候,只有美国人和美国人交流才会这么说
    美国之外,没人明白啥 PST ,EST ,CST 这些玩意儿
    gesse
        52
    gesse  
       183 天前
    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
    Jiceburger
        53
    Jiceburger  
       183 天前 via Android
    中部时间 CST 比 UTC 多一个好处,就是自带冬令时夏令时属性… 中部时间的 UTC 在冬天夏天是不一样的。
    Biggoldfish
        54
    Biggoldfish  
       183 天前
    @Jiceburger

    CST 目前情况下一定是 UTC -6 吧,夏令时会用 CDT (UTC -5)

    当然日常使用懒得想是冬夏就直接 PT CT ET 了
    Jiceburger
        55
    Jiceburger  
       183 天前
    @Biggoldfish 你说的对,我记错了... 很多系统里确实有 CT 这个选项,自备了时区~
    AxtonYao
        56
    AxtonYao  
       183 天前 via iPhone   ❤️ 1
    在大多数情况下还是建议使用 IANA 时区名称来表示时区,Unix 时间戳来存储时间,因为三字母时区名会冲突,同时一个国家/地区的 UTC 偏移可能会因为各种原因变动,只存储 UTC 偏移是不够的
    https://flyhigher.top/develop/2482.html
    当然也看见过 MySQL 在设置为 IANA 时区的情况下,拒接解析夏令时切换时的“消失的时间”字符串为时间戳,没有 fallback 直接报错的问题,所以具体用什么怎么做还是要看具体需求
    chapiom
        57
    chapiom  
       183 天前
    @whileFalse 还是不用好,太容易搞错了
    MuSeCanYang
        58
    MuSeCanYang  
       121 天前
    我们用 BJT ....
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   1035 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 73ms · UTC 19:18 · PVG 03:18 · LAX 12:18 · JFK 15:18
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.