Internationalization: NaN and Infinity in date formatting

[Norbert Lindenberg]

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: 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
>>> 
>> _______________________________________________
>> 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