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

I am throwing an amazing exception in FireFox 38.0.1 (a new install of the latest version at the time of writing) while 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 does not like to use the formatting RangeError: invalid time zone in DateTimeFormat(): AMERICA/NEW_YORK and responds as such: RangeError: invalid time zone in DateTimeFormat(): AMERICA/NEW_YORK

Does FireFox support IANA time zones when implementing date formatting methods (e.g. Date.prototype.toLocaleString, Intl.DateTimeFormat, etc.)?

+6
source share
1 answer

Please note that ECMA-402 makes IANA time zones a purely optional requirement. It seems that Firefox does not currently support them.

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

  1. Let tz be the result of calling the [[Get]] internal option method with the argument " timeZone ".
  2. If tz is not undefined, then
    • a. Let tz be ToString (tz).
    • b. Convert tz to uppercase as described in 6.1.
      NOTE. If the implementation accepts additional time zone values, as permitted under certain conditions in accordance with the matching condition, various casing rules apply.
    • with. If tz is not " UTC " then throw a RangeError exception.

But, as noted in NOTE, values ​​other than UTC may be supported:

The corresponding implementation is allowed to take additional values ​​and then have the behavior defined by the implementation, instead of throwing a RangeError for the following properties of the option arguments:

[...]

The value of the timeZone property in the DateTimeFormat constructor, provided that the additional valid input values ​​are not case-sensitive for zone identifiers or references in the IANA time zone database and canonicalized for zone identifiers in the case used in the database for the timeZone property of the object returned by DateTimeFormat.resolvedOptions, except that "Etc / GMT" must be canonized in "UTC".

If we look at InitializeDateTimeFormat in /js/src/builtin/Intl.js , we will see the implementation of these 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); } 

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

+7
source

Source: https://habr.com/ru/post/987681/


All Articles