JavaScript Intl API在Chrome中提供不同的结果 [英] JavaScript Intl API gives different results in Chrome

问题描述

我正在使用JavaScript Intl API在浏览器中检测用户的时区：

I am using JavaScript Intl API to detect the user's timezone in the browser:

Intl.DateTimeFormat().resolvedOptions().timeZone

此API 看起来很稳定，我不知道接下来该怎么做。在我的Windows 10计算机上，时区设置为美国东部标准时间：

While this API looks stable, I don't know what to do with the next. On my Windows 10 machine, the timezone is set to US Eastern Standard Time:

C:\> tzutil /g
US Eastern Standard Time

在Firefox和Edge中，上述JavaScript代码结果如下： 美国/印第安纳州/印第安纳波利斯 ，而Chrome仅返回美国/印第安纳波利斯 。

In Firefox and Edge the above JavaScript code results with "America/Indiana/Indianapolis", while Chrome returns just "America/Indianapolis".

为什么在不同的浏览器中会产生不同的结果？是Chrome的bug，还是我应该在服务器上处理时区之前改变时区？

Why this yields different results in different browsers? Is it a Chrome bug or should I transform the time zones somehow before processing them on the server?

在Ubuntu（这是服务器的操作系统）上，如果我列出了可用时间具有 timedatectl list-timezones 的区域，有美国/印第安纳州/印第安纳波利斯 ，但没有 美国/印第安纳波利斯 。由于这个问题，我无法从客户端接受Chrome的美国/印第安纳波利斯 ，因为我从的输出中获取了可用时区列表 timedatectl list-timezones 。我应该在这里采取哪种行为？

On Ubuntu (which is my server's OS), if I list available time zones with timedatectl list-timezones, there is "America/Indiana/Indianapolis", but there is no "America/Indianapolis". Because of this issue I cannot accept Chrome's "America/Indianapolis" from the client, as I grab the "available time zones list" from the output of timedatectl list-timezones. Which behavior should I apply here?

我们将提供任何帮助。谢谢！

Any help is appreciated. Thank you!

推荐答案

Chrome与许多其他浏览器一样，通过 ICU ，它依次来自 CLDR ，部分来自 IANA 。

Chrome, like many others, gets its time zone information through ICU, which in turn sources from CLDR, which in part sources from IANA.

IANA和CLDR在规范化方面有细微的差别。

There is a subtle difference between IANA and CLDR with regard to canonicalization.

• IANA将时区标识符的首选形式视为规范形式。如果首选表单发生更改，它们将成为新的主表单（ Zone 条目），并将旧的表单移至别名（ Link 条目。）

• IANA treats the preferred form of the time zone identifier as canonical. If the preferred form changes, they make the new one primary (a Zone entry) and move the old one to an alias (a Link entry).

CLDR将时区标识符的 first 形式视为规范形式。也就是说，它第一次出现在CLDR中，永远被锁定。如果出现了新表格，则将其作为别名添加到 /common/bcp47/timezone.xml 文件。

CLDR treates the first form of the time zone identifier as canonical. That is, the first time it appeared in CLDR, it is locked in forever. If a new form ever appears, it is added as an alias in the /common/bcp47/timezone.xml file.

以印第安纳波利斯为例：

Taking your case of Indianapolis:

• IANA区域条目（参考此处）

Zone    America/Indiana/Indianapolis    ...

IANA链接条目（此处引用）

Link    America/Indiana/Indianapolis    America/Indianapolis

在CLDR中，主要区域首先在别名属性中列出，然后是其他别名。 （此处引用）

<type name="usind" description="Indianapolis, United States" alias="America/Indianapolis America/Fort_Wayne America/Indiana/Indianapolis US/East-Indiana"/>

<$可以找到相同的东西c $ c>亚洲/加尔各答与亚洲/加尔各答和其他几个示例。

此外，请注意，Windows时区映射也来自CLDR，位于 /common/supplemental/windowsZones.xml 文件。您会在此处注意到，美国东部标准时间已映射到美国/印第安纳波利斯。 因此，浏览器之间的差异在很大程度上取决于要遵循的规范化规则。

Additionally, be aware that the Windows time zone mappings also source from CLDR, in the /common/supplemental/windowsZones.xml file. You'll notice there that US Eastern Standard Time is mapped to America/Indianapolis. So the difference between browsers depends very much on which canonicalization rules are followed.

最后，实际上哪个别名并不重要用过的。它们指向相同的数据。

In the end, it doesn't really matter which alias is used. They point at the same data.

还值得指出的是，只有在关心印第安纳州的历史时间变化。如果您只是在美国东部时区，则应将系统设置为东部标准时间 ，而不是美国东部标准时间 。 （是的，这些ID令人困惑...）

Also worth pointing out, that particular Windows zone should only be selected if you care about historical time changes in Indiana. If you are just in the US Eastern time zone, you should set your system to "Eastern Standard Time", rather than "US Eastern Standard Time". (Yes, those IDs are confusing...)

这篇关于JavaScript Intl API在Chrome中提供不同的结果的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！