Last Comment Bug 58007 - ECMA Conformance: missing Date.to(Date|Time)String() functions
: ECMA Conformance: missing Date.to(Date|Time)String() functions
Status: VERIFIED FIXED
[rtm-] fix in trunk
: js1.5
Product: Core
Classification: Components
Component: JavaScript Engine (show other bugs)
: Trunk
: All All
: P3 normal (vote)
: ---
Assigned To: Mike McCabe
: Phil Schwartau
Mentors:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2000-10-25 17:06 PDT by David Flanagan
Modified: 2013-06-29 02:27 PDT (History)
7 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
add toDateString, toTimeString (5.02 KB, patch)
2000-10-31 18:13 PST, Mike McCabe
no flags Details | Diff | Splinter Review

Description David Flanagan 2000-10-25 17:06:04 PDT
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.
Comment 1 Phil Schwartau 2000-10-25 21:20:28 PDT
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 - 
Comment 2 Phil Schwartau 2000-10-25 21:22:06 PDT
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.
Comment 3 Mike McCabe 2000-10-26 17:36:39 PDT
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.)
Comment 4 Brendan Eich [:brendan] 2000-10-26 20:08:52 PDT
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
Comment 5 Brendan Eich [:brendan] 2000-10-28 19:02:34 PDT
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
Comment 6 Mike McCabe 2000-10-31 18:13:25 PST
Created attachment 18422 [details] [diff] [review]
add toDateString, toTimeString
Comment 7 Mike McCabe 2000-10-31 18:13:52 PST
Fixes attached, possibly too late ?
Comment 8 Brendan Eich [:brendan] 2000-11-01 11:35:30 PST
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
Comment 9 John Bandhauer 2000-11-01 11:59:48 PST
sr=jband. Looks good!
Comment 10 Brendan Eich [:brendan] 2000-11-01 13:55:34 PST
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
Comment 11 Mike McCabe 2000-11-01 15:58:08 PST
Fix in trunk.
Comment 12 selmer (gone) 2000-11-01 16:44:20 PST
rtm-, what real-world pages will be broken by this?  Looks like a good thing to 
get on the trunk though.
Comment 13 Brendan Eich [:brendan] 2000-11-01 16:50:00 PST
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
Comment 14 Mike McCabe 2000-11-01 17:11:56 PST
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.
Comment 15 Brendan Eich [:brendan] 2000-11-01 17:18:46 PST
One more try for Netscape 6, based on mccabe's last comment.

/be
Comment 16 David Flanagan 2000-11-01 21:16:10 PST
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!
Comment 17 selmer (gone) 2000-11-02 17:08:17 PST
rtm-, not ship stopper.
Comment 18 Jason Eager 2000-11-02 19:49:12 PST
*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?
Comment 19 Jason Eager 2000-11-06 13:40:00 PST
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).
Comment 20 David Flanagan 2000-11-06 13:51:27 PST
The URL that jce2 is looking for is 
http://www.oreilly.com/news/flanagan_1100.html
Comment 21 Jason Eager 2000-11-06 13:54:12 PST
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."
Comment 22 Phil Schwartau 2000-11-25 19:00:50 PST
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 -
Comment 23 Boris Zbarsky [:bz] 2000-11-29 07:56:15 PST
The fix for this is in the trunk.  Should this be marked fixed, or are we
keeping it open for 6.01?
Comment 24 Mike McCabe 2000-12-28 16:50:34 PST
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.
Comment 25 Phil Schwartau 2000-12-29 16:15:03 PST
Verified on Linux, WinNT, and Mac -

Note You need to log in before you can comment on or make changes to this bug.