If throwing an exception from Date.prototype.toLocaleString is allowed, then I think that would be the best solution. I thought that would be considered an incompatible change since the spec doesn't mention it and no implementation (that I've tested with) does it.
Norbert On Jun 22, 2012, at 9:25 , Allen Wirfs-Brock wrote: > #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. doesn't seems -> seems? > 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 _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
