当我使用MomentJS或Internationalization API时，Chrome中的Asia/Katmandu或Asia/Calcutta等过时的时区!这些应该改为输出为Asia/Kathmandu和Asia/Kolkata。
我该如何解决？
最佳答案
您的问题有点误入歧途，因为tzdb中通常没有“过时”的时区。通常，一旦tzdb引入了标识符，它将继续无限期地支持它-作为Zone或Link。
仅有几个罕见的异常(exception):
Canada/East-Saskatchewan在版本2017c中已从tzdb中删除，因为它用词不当，并且超过了tzdb维护者设置的14个字符的限制。该区域的任何用法都应更新为America/Regina。US/Pacific-New在2020b版中已从tzdb中删除，因为它引起了很多困惑。它从来不是一个实时区域，而只是一个链接。该区域的任何用法都应更新为America/Los_Angeles。您提供的示例和列表表明您想要规范的
Zone条目，而不是别名Link条目。尽管两者均有效，并且所有tzdb实现均应正确解析链接，但实际上通常应优先考虑。因此，我可以理解您希望所有链接都得到解决的愿望。也就是说，当前数据文件构建器在moment-timezone中的实现在构建数据时不会区分TZDB区域和链接。相反，它为遇到的第一个唯一数据创建自己的区域条目，然后为随后的所有匹配项创建自己的链接条目。这样做的缺点是将tzdb规范区域放在前面和中间(这会影响较旧的浏览器中的API，例如
moment.tz.guess())，而且还具有能够链接数据文件涵盖的相同区域的优点。例如，如果您查看当前的
moment-timezone-with-data-2012-2022.js 文件，您会发现Europe/Paris是大多数使用CET / CEST的地方的唯一区域条目。其余的都是指向该文件中Europe/Paris的链接，即使是那些具有单独的规范tzdb区域的链接，例如Europe/Amsterdam，Europe/Berlin等。这种权衡是力矩时区的原始作者的设计决定，通常不会改变。这样可以使数据文件保持较小的大小。
另外，如果您针对的是现代浏览器(和/或Node.js)，我强烈建议改用Luxon。这是Moment团队提供的较新的库，并且具有无需提供数据文件即可支持时区的优点(因为大多数现代环境都支持Intl API)。
还值得注意的是，Intl API往往是通过ICU实现的，该ICU从TZDB中获取一些数据，而从CLDR中获取一些数据。这两个项目对“规范”的概念略有不同。基本上，CLDR中的规范区域是最先引入的区域，即使TZDB决定降级为链接并用新名称替换，它也不会改变。例如，您可能会从某些Intl实现中将
Asia/Calcutta作为印度的默认时区，因为CLDR认为它是规范的。这是另一个原因，尽管重要的是所有实现都等效地支持两种形式的标识符。