FireFox是否支持Date.prototype.toLocaleString()中的IANA时区？

Question

在执行以下代码时,我在FireFox 38.0.1(编写本文时的最新版本的全新安装)中遇到了一个令人惊讶的异常:

var d = new Date()
var formattingOptions = { timeZone: 'America/New_York', month: '2-digit', day: '2-digit', year: 'numeric', hour: 'numeric', minute: 'numeric', second: 'numeric' };
var formattedDate = d.toLocaleString('en-US', formattingOptions);

显然,FireFox不喜欢我使用formattingOptions.timeZone,并且响应如下: RangeError: invalid time zone in DateTimeFormat(): AMERICA/NEW_YORK

FireFox在日期格式化方法的实现中是否不支持IANA时区(例如Date.prototype.toLocaleString,Intl.DateTimeFormat等)？

Answer 1

请注意,ECMA-402使IANA时区成为纯粹的可选要求.似乎Firefox目前还没有选择支持它们.

默认行为是拒绝任何timeZone比其他值UTC在12.1.1.1:

15. 设tz是使用参数" timeZone" 调用[[Get]]选项的内部方法的结果.
16. 如果tz未定义,那么
    • 一个.设tz为ToString(tz).
    • 湾 如6.1所述,将tz转换为大写.
      注意:如果实现接受其他时区值,如某些条件允许的一致条款允许,则适用不同的大小写规则.
    • C.如果tz不是" UTC",则抛出RangeError异常.

但是,正如说明指出,除了UTC其它值可以被支持:

对于options参数的以下属性,允许一致的实现接受其他值,然后具有实现定义的行为而不是抛出RangeError:

[...]

DateTimeFormat构造函数中的options属性timeZone,前提是其他可接受的输入值是IANA时区数据库中区域或链接标识符的不区分大小写匹配,并且在数据库中用于timeZone属性的外壳中规范化为区域标识符DateTimeFormat.resolvedOptions返回的对象,除了"Etc/GMT"应规范化为"UTC".

如果我们看一下InitializeDateTimeFormat在/js/src/builtin/Intl.js,我们看到的从ECMA-402 12.1.1.1这些步骤实现:

 // Steps 15-17.
 var tz = options.timeZone;
 if (tz !== undefined) {
     tz = toASCIIUpperCase(ToString(tz));
     if (tz !== "UTC")
         ThrowRangeError(JSMSG_INVALID_TIME_ZONE, tz);
 }

显然,这拒绝timeZone除了以外的任何其他价值UTC,所以我认为我们可以有把握地断定Firefox toLocaleString还不支持IANA时区.