Re: Date.prototype.toISOString and Invalid Date

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 t

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

RE: ByteArray

I also think that some sort of byteArray/buffer abstraction should be on the table for Harmony discussions. After a quick glance, at the two proposals at I'm not sure particularly enthusiastic about either of them. But as Mark said, they could be a st

Re: Date.prototype.toISOString and Invalid Date

On Wed, 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. While I agree that throwing makes sense, it is not for t

Re: ByteArray

On Wed, Jun 10, 2009 at 10:28 AM, Anne van Kesteren wrote: > ECMAScript 4 had a ByteArray feature that the W3C WebApps WG wanted to use > for XMLHttpRequest Level 2, to expose the raw response data and also to > allow any entity body to be transmitted to the server the author could > think of. > >

RE: Date.prototype.toISOString and Invalid Date

Date.prototype.toJSON is defined (using pseudo code) to be generally equivalent to return this.toISOString(); From: Mark S. Miller [mailto:erig...@google.com] Sent: Wednesday, June 10, 2009 11:04 AM To: Allen Wirfs-Brock Cc: Brendan Eich; es5-disc...@mozilla.org; es-discuss@mozil

Re: Date.prototype.toISOString and Invalid Date

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

Re: Date.prototype.toISOString and Invalid Date

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

RE: Date.prototype.toISOString and Invalid Date

This would also imply that (new Date(NaN).toJSON()) also throws. Is everybody fine with that?? Allen >-Original Message- >From: Brendan Eich [mailto:bren...@mozilla.com] >Sent: Wednesday, June 10, 2009 9:42 AM >To: Allen Wirfs-Brock >Cc: John Cowan; Adam Peller; es-discuss@mozilla.org;

Fwd: ByteArray

I thought I'd try posting this again. --- Forwarded message --- From: "Anne van Kesteren" To: es-discuss@mozilla.org Cc: Subject: ByteArray Date: Thu, 16 Oct 2008 09:05:30 +0200 Hi, ECMAScript 4 had a ByteArray feature that the W3C WebApps WG wanted to use for XMLHttpRequest Level 2, to

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

RE: Date.prototype.toISOString and Invalid Date

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() sho

Re: Date.prototype.toISOString and 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

RE: Date.prototype.toISOString and Invalid Date

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 Numbe

Re: struct

Sam Ruby wrote: > Independent of any discussion of predefined numeric types, I believe > that there is a class of performance critical applications that could > benefit from an introduction of "structs" into ES. Additionally, such > an addition could make ES more attractive as a compilation target

Re: Date.prototype.toISOString and 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? On Wed, Jun 10, 2009 at 3:06 AM, Allen Wirfs-Brock wrote: > Currently, implementations are inconsisten