Internationalization: NaN and Infinity in date formatting

[Brendan Eich]

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: es-discuss-bounces at mozilla.org [es-discuss-bounces at mozilla.org] on behalf of Norbert Lindenberg [ecmascript at norbertlindenberg.com]
> 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
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>