Date.prototype.toISOString and Invalid Date

[Garrett]

What is the expected result of calling toISOString on a date where the
year is NaN?

var d = new Date(NaN);
d.toISOString();

?

Garrett
_______________________________________________
es-discuss mailing list
es-discuss@...
https://mail.mozilla.org/listinfo/es-discuss

[Allen Wirfs-Brock-2]

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

Allen

>-----Original Message-----
>From: es-discuss-bounces@... [mailto:es-discuss-
>bounces@...] On Behalf Of Garrett Smith
>Sent: Saturday, June 06, 2009 12:40 AM
>To: es-discuss
>Subject: Date.prototype.toISOString and Invalid Date
>
>What is the expected result of calling toISOString on a date where the
>year is NaN?
>
>var d = new Date(NaN);
>d.toISOString();
>
>?
>
>Garrett
>_______________________________________________
>es-discuss mailing list
>es-discuss@...
>https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
es-discuss@...
https://mail.mozilla.org/listinfo/es-discuss

[Christian Plesner Hansen-3]

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?

On Wed, Jun 10, 2009 at 3:06 AM, Allen
Wirfs-Brock<Allen.Wirfs-Brock@...> wrote:

> 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".
>
> Allen
>
>>-----Original Message-----
>>From: es-discuss-bounces@... [mailto:es-discuss-
>>bounces@...] On Behalf Of Garrett Smith
>>Sent: Saturday, June 06, 2009 12:40 AM
>>To: es-discuss
>>Subject: Date.prototype.toISOString and Invalid Date
>>
>>What is the expected result of calling toISOString on a date where the
>>year is NaN?
>>
>>var d = new Date(NaN);
>>d.toISOString();
>>
>>?
>>
>>Garrett
>>_______________________________________________
>>es-discuss mailing list
>>es-discuss@...
>>https://mail.mozilla.org/listinfo/es-discuss
>
> _______________________________________________
> es-discuss mailing list
> es-discuss@...
> https://mail.mozilla.org/listinfo/es-discuss
>

_______________________________________________
es-discuss mailing list
es-discuss@...
https://mail.mozilla.org/listinfo/es-discuss

[Adam Peller-5]

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 ---06/09/2009 09:07:00 PM---Currently, implementations are inconsistent about what they produce for (new Date(NaN).toString()).

Allen Wirfs-Brock <Allen.Wirfs-Brock@...>
Sent by: es5-discuss-bounces@...

06/09/2009 09:06 PM

To	"es5-discuss@..." <es5-discuss@...>, "es-discuss@..." <es-discuss@...>
cc	Garrett Smith <dhtmlkitchen@...>
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".

Allen

>-----Original Message-----
>From: es-discuss-bounces@... [...
>bounces@...] On Behalf Of Garrett Smith
>Sent: Saturday, June 06, 2009 12:40 AM
>To: es-discuss
>Subject: Date.prototype.toISOString and Invalid Date
>
>What is the expected result of calling toISOString on a date where the
>year is NaN?
>
>var d = new Date(NaN);
>d.toISOString();
>
>?
>
>Garrett
>_______________________________________________
>es-discuss mailing list
>es-discuss@...
>https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es5-discuss mailing list
es5-discuss@...
https://mail.mozilla.org/listinfo/es5-discuss





_______________________________________________
es-discuss mailing list
es-discuss@...
https://mail.mozilla.org/listinfo/es-discuss

[Adam Peller-5]

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 ---06/10/2009 11:21:08 AM---Adam Peller scripsit:

John Cowan <cowan@...>

06/10/2009 11:21 AM

To	Adam Peller/Cambridge/IBM@IBMUS
cc	Allen Wirfs-Brock <Allen.Wirfs-Brock@...>, "es5-discuss@..." <es5-discuss@...>, Garrett Smith <dhtmlkitchen@...>, "es-discuss@..." <es-discuss@...>
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 times of peril or dubitation,          http://www.ccil.org/~cowan
Perform swift circular ambulation,
With loud and high-pitched ululation.





_______________________________________________
es-discuss mailing list
es-discuss@...
https://mail.mozilla.org/listinfo/es-discuss

[Allen Wirfs-Brock-2]

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.

Allen

>-----Original Message-----
>From: John Cowan [mailto:cowan@...]
>Sent: Wednesday, June 10, 2009 8:21 AM
>To: Adam Peller
>Cc: Allen Wirfs-Brock; es5-discuss@...; Garrett Smith; es-
>discuss@...
>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 times of peril or dubitation,          http://www.ccil.org/~cowan
>Perform swift circular ambulation,
>With loud and high-pitched ululation.

_______________________________________________
es-discuss mailing list
es-discuss@...
https://mail.mozilla.org/listinfo/es-discuss

[Brendan Eich-3]

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.

/be

_______________________________________________
es-discuss mailing list
es-discuss@...
https://mail.mozilla.org/listinfo/es-discuss

[Allen Wirfs-Brock-2]

This would also imply that (new Date(NaN).toJSON()) also throws.  Is everybody fine with that??

Allen

>-----Original Message-----
>From: Brendan Eich [mailto:brendan@...]
>Sent: Wednesday, June 10, 2009 9:42 AM
>To: Allen Wirfs-Brock
>Cc: John Cowan; Adam Peller; es-discuss@...; es5-
>discuss@...
>Subject: Re: Date.prototype.toISOString and Invalid Date
>
>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.
>
>/be
>

_______________________________________________
es-discuss mailing list
es-discuss@...
https://mail.mozilla.org/listinfo/es-discuss

[Mark S. Miller-2]

On Wed, Jun 10, 2009 at 11:00 AM, Allen Wirfs-Brock <Allen.Wirfs-Brock@...> 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?

--
   Cheers,
   --MarkM

_______________________________________________
es-discuss mailing list
es-discuss@...
https://mail.mozilla.org/listinfo/es-discuss

[Brendan Eich-3]

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.

/be

>
> Allen
>
>> -----Original Message-----
>> From: Brendan Eich [mailto:brendan@...]
>> Sent: Wednesday, June 10, 2009 9:42 AM
>> To: Allen Wirfs-Brock
>> Cc: John Cowan; Adam Peller; es-discuss@...; es5-
>> discuss@...
>> Subject: Re: Date.prototype.toISOString and Invalid Date
>>
>> 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.
>>
>> /be
>>
>

_______________________________________________
es-discuss mailing list
es-discuss@...
https://mail.mozilla.org/listinfo/es-discuss

[Allen Wirfs-Brock-2]

Some parts of this message have been removed. Learn more about Nabble's security policy.

Date.prototype.toJSON is defined (using pseudo code) to be generally equivalent to

               return this.toISOString();

 

 

 

From: Mark S. Miller [mailto:erights@...]
Sent: Wednesday, June 10, 2009 11:04 AM
To: Allen Wirfs-Brock
Cc: Brendan Eich; es5-discuss@...; es-discuss@...
Subject: Re: Date.prototype.toISOString and Invalid Date

 

On Wed, Jun 10, 2009 at 11:00 AM, Allen Wirfs-Brock <Allen.Wirfs-Brock@...> 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?

--
   Cheers,
   --MarkM

_______________________________________________
es-discuss mailing list
es-discuss@...
https://mail.mozilla.org/listinfo/es-discuss

[Garrett]

On Wed, Jun 10, 2009 at 8:48 AM, Allen
Wirfs-Brock<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.

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!)

Regards,

Garrett
_______________________________________________
es-discuss mailing list
es-discuss@...
https://mail.mozilla.org/listinfo/es-discuss

[Douglas Crockford]

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.


_______________________________________________
es-discuss mailing list
es-discuss@...
https://mail.mozilla.org/listinfo/es-discuss

[Adam Peller-5]

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?

-Adam
_______________________________________________
es-discuss mailing list
es-discuss@...
https://mail.mozilla.org/listinfo/es-discuss

[Garrett]

On Wed, Jun 10, 2009 at 8:56 PM, Adam Peller<apeller@...> 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
_______________________________________________
es-discuss mailing list
es-discuss@...
https://mail.mozilla.org/listinfo/es-discuss

[Allen Wirfs-Brock-2]

>-----Original Message-----
>From: es-discuss-bounces@... [mailto:es-discuss-
>bounces@...] 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.

Allen
_______________________________________________
es-discuss mailing list
es-discuss@...
https://mail.mozilla.org/listinfo/es-discuss