如何从 JavaScript Intl.DateTimeFormat 获取时区缩写

8
我正在尝试使用ECMA-402国际API来获取不是本地时区(服务器时区为UTC)的时区缩写。我知道其他获取方法,但我想了解国际API的限制并充分利用它。我可以获取完整的时区名称并自行映射,但由于缩写在IANA tz数据库中,而国际API应该基于此,因此它似乎应该能够生成它们,这让我认为我做错了什么。
我有以下代码:
    const fmt = new Intl.DateTimeFormat('en', {
        year: 'numeric',
        month: '2-digit',
        day: '2-digit',
        hour: '2-digit',
        minute: '2-digit',
        second: 'numeric',
        fractionalSecondDigits: 3,
        hour12: false,
        weekday: 'short',
        timeZoneName: 'short',
        timeZone: 'Pacific/Auckland' 
    });

    const now = new Date();
    console.log(fmt.format(now));

    const fmt2 = new Intl.DateTimeFormat('en', {
        year: 'numeric',
        month: '2-digit',
        day: '2-digit',
        hour: '2-digit',
        minute: '2-digit',
        second: 'numeric',
        fractionalSecondDigits: 3,
        hour12: false,
        weekday: 'short',
        timeZoneName: 'short',
        timeZone: 'America/Los_Angeles' 
    });

    console.log(fmt2.format(now));

在node 12.16.1和Firefox 73.0.1中,这将产生如下输出:
Wed, 04/08/2020, 18:14:50 GMT+12
Tue, 04/07/2020, 23:14:50 PDT

美国洛杉矶时区按预期获取时区缩写,但太平洋/奥克兰时区没有。IANA tz数据库具有Pacific/Auckland的缩写,并且操作系统(Debian Linux)会生成它们。

是否有什么不同的方法可以从国际API获取缩写?还是这就是现状?

我注意到,luxon和date-fns-tz都依赖于国际API,它们也无法生成Pacific/Auckland的缩写。

1个回答

8
大多数ECMAScript国际化API的实现从Unicode CLDR获取时区缩写字符串,而不是从IANA获取。 IANA中的缩写仅限于英语,并且许多已在最近几年中被删除,因为发现它们是虚构的。
不幸的是,CLDR数据集中实际上只包含了很少的时区缩写。
总的来说,时区缩写很难达成一致。 在几种情况下,同一时区使用多个缩写。 有些文化会切换到英语缩写,而其他文化则使用自己语言的缩写,许多文化根本不使用缩写。
鉴于所有这些,我认为您仍应使用Intl API给出的输出。 如果可用缩写,则将其显示出来,否则将显示数字偏移量。 是的-这就是当前的技术水平。

感谢您提供Unicode CLDR的参考。我之前并不知道它的存在。而且我误解了ECMA-402第6.4节,认为应该使用IANA数据库,而实际上它只是指出其中的区域和链接名称应该被使用。这对于我理解的纠正非常有帮助。 - Ian
1
是的,CLDR也使用IANA区域/链接名称作为规范参考。通常,IANA是偏移/转换的来源,而CLDR是本地化的来源。缩写词处于奇怪的灰色地带,在两者中都处理得很差。虽然它们是我们拥有的最接近标准的东西,但两者都不承认自己是“标准”。 - Matt Johnson-Pint

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文,
原文链接