如果我们在系统中选择“（UTC +01:00）布鲁塞尔，哥本哈根，马德里，巴黎”，则两种浏览器的输出都不同。
var tz = jstz.determine();
var tzName = tz.name();
输出：
IE11：欧洲/柏林
Chrome：欧洲/巴黎
【问题讨论】：
Intl api 如果可用 (-> line 408ff.) 否则它使用自己的名称“数据库”。 Europe/Berlin 来自内部“数据库”，Europe/Paris 来自 Intl。 IE11 不支持Intl.DateTimeFormat.resolvedOptions().timeZone
.determine() 不要使用 Intl）
标签： javascript jquery timezone
来自jsTimeZoneDetect 文档：
限制
这个脚本不做地理定位，也不太关心历史时区。因此，如果您对“Europe/Berlin”时区不满意，而用户实际上位于“Europe/Stockholm”，那么此脚本不适合您。它们在现代是相同的。
确实，如果我们仔细检查和比较 Berlin 和 Paris 的时区变化历史，我们会发现它们自 1980 年以来一直是相同的。因此，除非您的应用程序处理的是 1980 年之前的日期，否则它是无论您检测到Europe/Berlin 还是Europe/Paris，都无关紧要。
至于哪个更正确，CLDR windowsZones.xml文件（这是Windows和IANA时区之间的规范映射）contains the following：
<!-- (UTC+01:00) Brussels, Copenhagen, Madrid, Paris -->
<mapZone other="Romance Standard Time" territory="001" type="Europe/Paris"/>
Chrome 使用 Intl API，该 API 在内部使用包含 CLDR 数据的 ICU。因此，Chrome 提供了更正确的答案。您应该在 FireFox、Edge 和其他现代网络浏览器中得到相同的答案。
Internet Explorer 较旧，不包含正确解决此问题所需的数据。因此，像 jsTimeZoneDetect 之类的库（以及通过 moment.tz.guess() 的时刻时区）首先尝试使用 Intl 方法，但是当不可用时，它们会通过测试各种已知时间点的 UTC 偏移变化来做出有根据的猜测。由于只是猜测，因此有时会不准确。
如果您有兴趣，有一个社区维护的compatibility chart 跟踪哪些浏览器支持“正确”时区检测过程。展开“DateTimeFormat”部分并检查标记为“resolvedOptions().timeZone defaults to the host environment”的行
【讨论】：