Date.prototype.toISOString and Invalid Date
Currently, implementations are inconsistent about what they produce for (new Date(NaN).toString()). IE and Opera produce "NaN", while FF and Safari produce "Invalid Date".
Since toISOString is a new function, we have the opportunity to specify what we want the result to be.
Does anybody have an opinion. It could be either "NaN" or "Invalid Date" or something else. "Invalid Date" has the advantage that it is more end-user meaningful if it actually leaks through to be visible on a web page (although that is a pretty Anglo-centric perspective).
Unless, I here strong opinions otherwise I think I'll go with "Invalid Date".
If the spec says that toISOString() must return a certain value that doesn't parse according to 15.9.1.15 maybe, for symmetry, it should also say what Date.parse should do when passed that value?
I don't feel strongly on this, but it does strike me as odd that a function intended to avoid culturally-sensitive output would use an English phrase. I'd lean towards IE/Opera, using notation from ECMAScript that is equally cryptic to all cultures :-) At least that would be consistent with Number.toString() and would reinforce the fact that there are other methods to produce strings in the user's locale.
Are there English phrases specified anywhere else for output?
-Adam
Allen Wirfs-Brock
<Allen.Wirfs-Broc
k at microsoft.com> To
Sent by: "es5-discuss at mozilla.org"
es5-discuss-bounc <es5-discuss at mozilla.org>,
es at mozilla.org "es-discuss at mozilla.org"
<es-discuss at mozilla.org>
cc
06/09/2009 09:06 Garrett Smith
PM <dhtmlkitchen at gmail.com>
Subject
RE: Date.prototype.toISOString and
Invalid Date
Currently, implementations are inconsistent about what they produce for (new Date(NaN).toString()). IE and Opera produce "NaN", while FF and Safari produce "Invalid Date".
Since toISOString is a new function, we have the opportunity to specify what we want the result to be.
Does anybody have an opinion. It could be either "NaN" or "Invalid Date" or something else. "Invalid Date" has the advantage that it is more end-user meaningful if it actually leaks through to be visible on a web page (although that is a pretty Anglo-centric perspective).
Unless, I here strong opinions otherwise I think I'll go with "Invalid Date".
NaN is already part of the ECMAScript language. There is an underlying Number representation of Date, but I'll grant you it's not a perfect fit as there are no Date literals. Returning null is another option, I suppose, but one that's likely to create even more problems.
-Adam
John Cowan
<cowan at ccil.org>
To
06/10/2009 11:21 Adam Peller/Cambridge/IBM at IBMUS
AM cc
Allen Wirfs-Brock
<Allen.Wirfs-Brock at microsoft.com>,
"es5-discuss at mozilla.org"
<es5-discuss at mozilla.org>, Garrett
Smith <dhtmlkitchen at gmail.com>,
"es-discuss at mozilla.org"
<es-discuss at mozilla.org>
Subject
Re: Date.prototype.toISOString and
Invalid Date
Adam Peller scripsit:
I don't feel strongly on this, but it does strike me as odd that a function intended to avoid culturally-sensitive output would use an English phrase. I'd lean towards IE/Opera, using notation from ECMAScript that is equally cryptic to all cultures :-) At least that would be consistent with Number.toString() and would reinforce the fact that there are other methods to produce strings in the user's locale.
In fact, "NaN" is an abbreviation of an English phrase, namely "not a number". But neither dates nor date strings are numbers. What say you to "NaD"?
-- John Cowan cowan at ccil.org At times of peril or dubitation, www.ccil.org/~cowan Perform swift circular ambulation, With loud and high-pitched ululation.
I believe that support for ISO dates in ES5 is intended to provide a standard interchange format for dates, not for providing a locale customized format for human consumption. Since ISO 8601 apparently doesn't provide an encoding for "invalid date/time", arguably new Date(NaN).toISOString() should never be passed to someone expecting a valid ISO date. If that is true, then be best thing to do may be to specify that toISOString throws a RangeError when applied to such Date objects.
On Jun 10, 2009, at 8:48 AM, Allen Wirfs-Brock wrote:
I believe that support for ISO dates in ES5 is intended to provide a
standard interchange format for dates, not for providing a locale
customized format for human consumption. Since ISO 8601 apparently
doesn't provide an encoding for "invalid date/time", arguably new
Date(NaN).toISOString() should never be passed to someone expecting
a valid ISO date. If that is true, then be best thing to do may be
to specify that toISOString throws a RangeError when applied to such
Date objects.
+1, or more.
This would also imply that (new Date(NaN).toJSON()) also throws. Is everybody fine with that??
On Wed, Jun 10, 2009 at 11:00 AM, Allen Wirfs-Brock < Allen.Wirfs-Brock at microsoft.com> wrote:
This would also imply that (new Date(NaN).toJSON()) also throws. Is everybody fine with that??
I must be missing something. How does that follow?
On Jun 10, 2009, at 11:00 AM, Allen Wirfs-Brock wrote:
This would also imply that (new Date(NaN).toJSON()) also throws. Is
everybody fine with that??
Too much of the cheese-whiz that is still dried up and stuck to the
language from 1995 (JS in Netscape 2) or 1997 (ES1 in Ecma) came about
because of lack of try/catch. Read-only assignment was a fail-stop
error condition in Netscape 2 if memory serves, but this was
considered too harsh without try/catch, so ES1 went with silent but
deadly failure to update.
In the modern world, when you can't encoding a value as an ISO string
or JSON, throwing is absolutely the right answer.
RFC 4627 says "Numeric values that cannot be represented as sequences
of digits (such as Infinity and NaN) are not permitted."
ES5 draft 15.9.5.44 Date.prototype.toJSON says "This function returns
the same string as Date.prototype.toISOString()."
Works for me.
Date.prototype.toJSON is defined (using pseudo code) to be generally equivalent to return this.toISOString();
From: Mark S. Miller [mailto:erights at google.com] Sent: Wednesday, June 10, 2009 11:04 AM To: Allen Wirfs-Brock Cc: Brendan Eich; es5-discuss at mozilla.org; es-discuss at mozilla.org Subject: Re: Date.prototype.toISOString and Invalid Date
On Wed, Jun 10, 2009 at 11:00 AM, Allen Wirfs-Brock <Allen.Wirfs-Brock at microsoft.com<mailto:Allen.Wirfs-Brock at microsoft.com>> wrote:
This would also imply that (new Date(NaN).toJSON()) also throws. Is everybody fine with that??
I must be missing something. How does that follow?
On Wed, Jun 10, 2009 at 8:48 AM, Allen Wirfs-Brock<Allen.Wirfs-Brock at microsoft.com> wrote:
I believe that support for ISO dates in ES5 is intended to provide a standard interchange format for dates, not for providing a locale customized format for human consumption.
While I agree that throwing makes sense, it is not for that reason.
ISO 8601 is intended for human consumption.
It would be useful for toISOString to allow the caller to provide a format.
[...]
(again, inline replies help keep the thread continuity -- thanks!)
,
Garrett
Adam Peller scripsit:
I don't feel strongly on this, but it does strike me as odd that a function intended to avoid culturally-sensitive output would use an English phrase. I'd lean towards IE/Opera, using notation from ECMAScript that is equally cryptic to all cultures :-) At least that would be consistent with Number.toString() and would reinforce the fact that there are other methods to produce strings in the user's locale.
I think this is what exceptions are for. An English string makes little sense. NaN is nonsense.
Douglas Crockford writes:
Adam Peller scripsit:
I don't feel strongly on this, but it does strike me as odd that a function intended to avoid culturally-sensitive output would use an English phrase. I'd lean towards IE/Opera, using notation from ECMAScript that is equally cryptic to all cultures :-) At least that would be consistent with Number.toString() and would reinforce the fact that there are other methods to produce strings in the user's locale.
I think this is what exceptions are for. An English string makes little sense. NaN is nonsense.
For toISOString I also favor an exception. The toString reference threw me off, since toString would not be able to throw in the invalid case and remain compatible. toString Implementations could certainly call toISOString, catch the exception, and choose some nonsensical, unspecified replacement, in which case we don't address the browser deviations, and that's probably fine. At one point, I think we discussed providing guidance for toString implementations to use toISOString. Was that deemed too likely to cause compatibility issues, or is it better to just leave the specification open here?
On Wed, Jun 10, 2009 at 8:56 PM, Adam Peller<apeller at us.ibm.com> wrote:
Douglas Crockford writes:
Adam Peller scripsit:
I don't feel strongly on this, but it does strike me as odd that a function intended to avoid culturally-sensitive output would use an English phrase. I'd lean towards IE/Opera, using notation from ECMAScript that is equally cryptic to all cultures :-) At least that would be consistent with Number.toString() and would reinforce the fact that there are other methods to produce strings in the user's locale.
I think this is what exceptions are for. An English string makes little sense. NaN is nonsense.
For toISOString I also favor an exception. The toString reference threw me off, since toString would not be able to throw in the invalid case and remain compatible. toString Implementations could certainly call toISOString, catch the exception, and choose some nonsensical, unspecified replacement,
Implementation of toString would probably not want to use try catch. They might rather do something along the lines of:-
If the date is finite, return an implementation-dependent string (which could be the resutl of toISOString). Otherwise, return an implementation-dependent string (such as "invalid date").
A native method for generating a few of the popular or common ISO 8601 formats, such as the extended YYYY-MM-DD seems useful, to me. Is it just me?
It seems that an "es5-discuss" list was created. I'm only subscribing to es-discuss. It that a deprecated list? What is the difference between these lists?
Garrett
-----Original Message----- From: es-discuss-bounces at mozilla.org [mailto:es-discuss- bounces at mozilla.org] On Behalf Of Garrett Smith Sent: Thursday, June 11, 2009 1:25 AM
It seems that an "es5-discuss" list was created. I'm only subscribing to es-discuss. It that a deprecated list? What is the difference between these lists?
es5-discuss is intended to be specifically about issues concerning the ES5 specification and its development and testing. es-discuss is for broader discussion of ECMAScript language futures including discussions relating to ES Harmony development.
What is the expected result of calling toISOString on a date where the year is NaN?
var d = new Date(NaN); d.toISOString();
?
Garrett