Internationalization: NaN and Infinity in date formatting

[Norbert Lindenberg]

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