Discuss
  • Internationalization: NaN and Infinity in date formatting

Internationalization: NaN and Infinity in date formatting

# Norbert Lindenberg (13 years ago)

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

# Eric Albright (13 years ago)

I think detection of programming errors is important enough that I favor option 3. Next in line is option 1.

# Brendan Eich (13 years ago)

Eric Albright wrote:

I think detection of programming errors is important enough that I favor option 3. Next in line is option 1.

Agreed.

# Allen Wirfs-Brock (13 years ago)

.#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.

# Phillips, Addison (13 years ago)

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

# Norbert Lindenberg (13 years ago)

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 Wirfs-Brock (13 years ago)

You're right, throwing is probably too much of a breaking change