The ECMAScript Internationalization API Specification currently requires that Intl.DateTimeFormat.prototype.format(date) throws an exception if ToNumber(date) is not a finite Number (i.e., it's NaN or +/- Infinity). This is incompatible with the specification of Date.prototype.toLocale(|Date|Time)String, which unconditionally requires that a String value is returned.
Most existing implementations of Date.prototype.toLocale(|Date|Time)String return "Invalid Date" for NaN (Infinity is mapped to NaN in the Date constructor). Safari tries to produce something in the format of a date string, with limited success: Mac OS 10.6.8: "December -2147483629, 1969 -596:-31:-23 GMT-08:00" iOS 5.1.1 German: "1. Januar 1970 00:00:00 GMT-07:52:58" Internationalization libraries usually use integer-based representations of date and time and therefore don't deal with NaN and Infinity. I see the following options: 1) Change Intl.DateTimeFormat.prototype.format to return a localized form of "Invalid Date" for non-finite values. Pro: Most compatible with current implementations. Con: Internationalization libraries probably don't provide these localized strings, so the wrapper implementing the ECMAScript Internationalization API has to provide them. 2) Change Intl.DateTimeFormat.prototype.format to return Intl.NumberFormat.prototype.format(ToNumber(date)) for non-finite values. Pro: Relies on existing functionality. Con: Less descriptive and less compatible than 1. 3) Leave Intl.DateTimeFormat.prototype.format as is (i.e., throw an exception for non-finite values); specify Date.prototype.toLocale(|Date|Time)String to handle NaN directly before calling Intl.DateTimeFormat.prototype.format with other values. Pro: Easier detection of programming errors when using format(). Con: format() and toLocaleString() start to drift apart. I lean towards option 1). Comments? Thanks, Norbert _______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
