#3 is also the alternative that seems right to me although since the "Invalid Date" behavior isn't in the standard and also isn't universal we could change the behavior of Date toLocaleString for ES6 and in the I18N API spec. to also throw.
"Invalid Date" doesn't seems to me like a debugging message and not something that requires or is intended for end-user localization. Allen On Jun 21, 2012, at 10:33 PM, Brendan Eich wrote: > Eric Albright wrote: >> I think detection of programming errors is important enough that I favor >> option 3. Next in line is option 1. > > Agreed. > > /be >> >> ________________________________________ >> From: [email protected] [[email protected]] on >> behalf of Norbert Lindenberg [[email protected]] >> Sent: Thursday, June 21, 2012 4:23 PM >> To: es-discuss >> Subject: Internationalization: NaN and Infinity in date formatting >> >> 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 >> [email protected] >> https://mail.mozilla.org/listinfo/es-discuss >> _______________________________________________ >> es-discuss mailing list >> [email protected] >> https://mail.mozilla.org/listinfo/es-discuss >> > _______________________________________________ > es-discuss mailing list > [email protected] > https://mail.mozilla.org/listinfo/es-discuss > _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
