Re: Internationalization: NaN and Infinity in date formatting
#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. 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-boun...@mozilla.org [es-discuss-boun...@mozilla.org] on behalf of Norbert Lindenberg [ecmascr...@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@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Internationalization: NaN and Infinity in date formatting
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-boun...@mozilla.org [es-discuss-boun...@mozilla.org] on behalf of Norbert Lindenberg [ecmascr...@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@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
RE: Internationalization: NaN and Infinity in date formatting
I prefer #3. The problem with #1 is that it's hard to detect--you always get a string back from the call and you have to inspect the string to find out that you don't want to display it to the user. Yuck. Even worse is that the string is localized and the caller can't be certain what that string will be on a given implementation. Double yuck. Addison -Original Message- From: Allen Wirfs-Brock [mailto:al...@wirfs-brock.com] Sent: Friday, June 22, 2012 9:25 AM To: Brendan Eich Cc: es-discuss Subject: Re: Internationalization: NaN and Infinity in date formatting #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. 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-boun...@mozilla.org [es-discuss-boun...@mozilla.org] on behalf of Norbert Lindenberg [ecmascr...@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@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Internationalization: NaN and Infinity in date formatting
You're right, throwing is probably too much of a breaking change Norbert Lindenberg ecmascr...@norbertlindenberg.com wrote: 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-boun...@mozilla.org [es-discuss-boun...@mozilla.org] on behalf of Norbert Lindenberg [ecmascr...@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@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
RE: Internationalization: NaN and Infinity in date formatting
I think detection of programming errors is important enough that I favor option 3. Next in line is option 1. From: es-discuss-boun...@mozilla.org [es-discuss-boun...@mozilla.org] on behalf of Norbert Lindenberg [ecmascr...@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@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Internationalization: NaN and Infinity in date formatting
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-boun...@mozilla.org [es-discuss-boun...@mozilla.org] on behalf of Norbert Lindenberg [ecmascr...@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@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
