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目前似乎还没有选择支持它们。

默认行为是拒绝12.1.1.1中timeZone以外的任何UTC值：

让 tz 成为使用参数＆＃34; timeZone＆＃34;调用[[Get]]选项的内部方法的结果。

如果 tz 未定义，那么

一个。设 tz 为ToString（ tz ）。

湾如<6.1>中所述，将 tz 转换为大写   注意：如果某个实现接受其他时区值，如某些条件允许的条件允许，则适用不同的大小写规则。

℃。如果 tz 不是＆＃34; UTC＆＃34;，则抛出RangeError例外。

但是，如注释中所述，除了以外的其他值可能：

允许符合条件的实现接受其他值，然后为options参数的以下属性提供实现定义的行为，而不是抛出RangeError：

[...]

DateTimeFormat构造函数中的选项属性timeZone，前提是其他可接受的输入值是IANA时区数据库中区域或链接标识符的不区分大小写匹配，并且已标准化为区域标识符。数据库中使用的套接字，用于DateTimeFormat.resolvedOptions返回的对象的timeZone属性，除了＆＃34; Etc / GMT＆＃34;应规范化为＆＃34; UTC＆＃34;。

如果我们查看/js/src/builtin/Intl.js中的InitializeDateTimeFormat，我们会看到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时区。

FireFox是否支持Date.prototype.toLocaleString（）中的IANA时区？

1 个答案: