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

我正在尝试使用ECMA-402国际API在一个非本地时区（服务器时区为UTC）的时区中获取时区缩写。我知道其他的方法。我试图了解国际API的局限性，并充分利用国际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的缩写。

大多数ECMAScript国际化API的实现都从IANA派生时区缩写字符串，而不是从IANA派生。IANA中的缩略语仅为英语，近年来许多缩略语被删除，因为人们发现它们是发明的

不幸的是，CLDR数据集中实际包含的时区缩写很少

一般来说，时区缩写很难达成一致。在某些情况下，同一时区使用多个缩写。一些文化转换为英语缩写，而另一些文化在自己的语言中有自己的缩写，许多文化根本不使用缩写

---

考虑到所有这些，我认为您仍然应该使用INTLAPI提供的输出。有缩写的地方有缩写，没有缩写的地方有数字偏移。是的-这是目前最先进的技术。

感谢您参考Unicode CLDR。我没有意识到。我误解了ECMA-402第6.4节，意思是要使用IANA数据库，而不是如它所说，要使用其中的区域和链接名称。这是对我理解的一个非常有用的更正。是的，CLDR还使用IANA区域/链接名称作为规范性参考。通常，IANA是偏移/转换的源，而CLDR是本地化的源。缩写词位于奇怪的灰色区域，在这两种语言中都处理得很糟糕。他们都不会承认自己是“标准”，尽管他们是我们最接近的标准。