Internationalization: NaN and Infinity in date formatting
ecmascript at norbertlindenberg.com
Thu Jun 21 16:23:16 PDT 2012
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).
More information about the es-discuss