js 1.5 rc2, at least the out-of-date tarball on ftp.mozilla.org/pub/js does not implement four date methods: toDateString(), toTimeString(), toLocaleDateString() and toLocaleTimeString(). See ECMA v3 spec, sections 15.9.5.3 to 15.9.5.7 Note that I am relying on the tarball version of 1.5rc2, which is out of date and reports the same version number as rc1.

Using JS Engine built 2000-10-25 on WinNT. I find that in the current code, these methods are in place: Date.toLocaleString() Date.toLocaleDateString() Date.toLocaleTimeString() But these are missing: Date.toDateString() Date.toTimeString() Reassigning to mccabe for Date expertise -

Here are the ECMA sections: 15.9.5.3 Date.prototype.toDateString ( ) This function returns a string value. The contents of the string are implementation-dependent, but are intended to represent the “date” portion of the Date in the current time zone in a convenient, human-readable form. 15.9.5.4 Date.prototype.toTimeString ( ) This function returns a string value. The contents of the string are implementation-dependent, but are intended to represent the “time” portion of the Date in the current time zone in a convenient, human-readable form.

Setting to assigned. David, would this work as a header for the Date section of your book ? "For example, OS/360 devotes 26 bytes of the permanently resident date-turnover routine to the proper handling of December 31 on leap years (when it is Day 366). That might have been left to the operator." Frederick Brooks, 'The Second-System Effect'. (from my .plan.)

Marking for js1.5. Unless the pdt gets really generous, Netscape 6 will ship with js1.4.999 (kidding, but you get the idea). /be

mccabe, any chance of a patch soon? This is one I would go to bat with the pdt for, to get the number of known ECMA-262 conformance bugs down to trivial ones. Fixing summary to reflect pschwartau's findings. /be

Fixes attached, possibly too late ?

Dude, use the CC: box! r=brendan@mozilla.org. Jband, can you sr= so we can get this into the trunk and [rtm+] it fast? There's a Limbo2 round going on today, I think. /be

sr=jband. Looks good!

mccabe, pls. get this into the trunk; pschwartau, tell us when the testsuite covers these bad boys. I'm marking [rtm+] and arguing briefly that these additions and parameterizations are safe for N6, because they don't break any existing functions (diff -wu would show that a bit more clearly). I'll let mccabe argue further, if the pdt needs more info. /be

Fix in trunk.

rtm-, what real-world pages will be broken by this? Looks like a good thing to get on the trunk though.

This is a standards purity fix, I doubt there are pages outside of firewalls, at least pages that don't sniff for IE5.x (whatever rev of IE supports these ECMA Edition 3 methods) and serve such method-bearing JS to those clients only. McCabe, your turn. /be

Sure, I'll add. This change is entirely within the JS engine, and just adds two new methods to the JS object. All interactions are local,and are limited to one commoned function. The commoned function can easily be shown to be equivalent to the old behavior. Zero risk. David Flanagan is writing a new edition of the O'Reilly JavaScript book, and he's expressed his sincere wish that he not have to document that Mozilla doesn't implement the ECMA-262 standard. These functions are not a behavioral corner case, but are genuinely useful to developers.

One more try for Netscape 6, based on mccabe's last comment. /be

As Mike said, these are genuinely useful functions. And as far as standards compliance goes, you can't get any more non-compliant than not implementing the API. You can probably get away with having a few functions that don't behave quite right in all cases, but you can't ship Netscape 6 and say it implements ECMAScript, when it does not even implement the complete API!

rtm-, not ship stopper.

*watches the PDT completely ignore all comments made above* David: Are you going to at least provide a (textual) link to this bug in your book when you explain why Netscape 6 isn't compliant?

PDT: There is now an article on OReilly net about how you are not going to fix this (and many other) standard compliance bugs that you have fixes in hand for. Your refusal has just gotten much higher profile. I'm trying to get the URL for this article again (I had it in an e-mail at home).

The URL that jce2 is looking for is http://www.oreilly.com/news/flanagan_1100.html

The URL for this article is: http://www.oreilly.com/news/flanagan_1100.html "There is also a high-profile link to the article from the O'Reilly & Associates home page."

Testcases added to JS test suite for ECMA3 sections 15.9.5.3 to 15.9.5.7: js/tests/ecma_3/Date/15.9.5.3.js - 15.9.5.7.js Note test 15.9.5.6.js is currently failing on Linux; bug 61183 has been filed -

The fix for this is in the trunk. Should this be marked fixed, or are we keeping it open for 6.01?

Fix has been checked in to trunk for a while, marking fixed per 6.01 checkin procedure; still hoping to get it checked in there.

Verified on Linux, WinNT, and Mac -