Does FireFox support IANA time zones in Date.prototype.toLocaleString()?

Question

I'm running into a surprising exception in FireFox 38.0.1 (a fresh install of the latest version at time of writing) when executing the following code:

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);

Apparently, FireFox doesn't like my use of formattingOptions.timeZone, and responds as such: RangeError: invalid time zone in DateTimeFormat(): AMERICA/NEW_YORK

Does FireFox not support IANA time zones in its implementation of Date formatting methods (e.g. Date.prototype.toLocaleString, Intl.DateTimeFormat, etc.)?

Answer 1

Note that ECMA-402 makes IANA time zones a purely optional requirement. It appears that Firefox currently has not opted to support them.

The default behavior is to reject any timeZone value other than UTC in 12.1.1.1:

15. Let tz be the result of calling the [[Get]] internal method of options with argument "timeZone".
16. If tz is not undefined, then
    • a. Let tz be ToString(tz).
    • b. Convert tz to upper case as described in 6.1.
      NOTE: If an implementation accepts additional time zone values, as permitted under certain conditions by the Conformance clause, different casing rules apply.
    • c. If tz is not "UTC", then throw a RangeError exception.

But, as noted in the NOTE, other values besides UTC may be supported:

A conforming implementation is permitted to accept additional values, and then have implementation-defined behaviour instead of throwing a RangeError, for the following properties of options arguments:

[...]

The options property timeZone in the DateTimeFormat constructor, provided that the additional acceptable input values are case-insensitive matches of Zone or Link identifiers in the IANA time zone database and are canonicalized to Zone identifiers in the casing used in the database for the timeZone property of the object returned by DateTimeFormat.resolvedOptions, except that "Etc/GMT" shall be canonicalized to "UTC".

If we look at InitializeDateTimeFormat in /js/src/builtin/Intl.js, we see an implementation of those steps from 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);
 }

Clearly, this rejects any timeZone value other than UTC, so I think we can safely conclude that Firefox's toLocaleString does not yet support IANA time zones.