To FootThis page is <http://www.merlyn.demon.co.uk/js-262-5.htm>.
Comment on the April 2009 Final Draft of ECMA 262 5th Edition (try the Wayback Machine for those) was offered in Summer 2009 to TC39.
Now that the 5th Edition is formally released, that comment has here been revised for consideration by those interested in a 6th Edition. Material applying only to 5th Edition Drafts should have been removed.
I have mainly studied the parts of the Standard for which I have some expertise, and merely looked through the rest.
Final Draft Standard ECMA-262
5th Edition / April 2009
(3.38 MB PDF)
includes :-
Final Draft Standard ECMA-262
5th Edition / September 2009
(2.85 MB PDF)
ECMA 5 – (2.36 MB PDF) – "This Ecma Standard has been adopted by the General Assembly of December 2009.". Not yet fully read.
It seems to me that, in the lists of lexical White Space, the references to <USP> are not optimally helpful. Taking Unicode 3.0 to be current but not necessarily final, in future simeone needing to know what ECMA 5th decrees may have to seek an outdated Unicode reference.
Can undefined become a proper literal yet?
In at least some more-or-less current (2009-09-12) browsers (IE 8, FF 3.0.13, Opera 9.64) undefined = 5 is accepted as an assignment, unlike null = 5 in at least one browser. Whatever the detailed explanation, both should be equally unacceptable; a typing-error like if (undefined = something) ... may cause great subsequent confusion.
Anything that looks as if it ought to be immutable ought to be immutable.
It is difficult to discuss, in English, whether undefined is defined or undefined. The type/value should have been called, for example, 'incogniti/incognitus'. Perhaps some alternative could be eased in.
CPU chips with IEEE 754 decimal floats are appearing. It would be well to specify how JavaScript should handle true decimal arithmetic, while leaving its implementation optional.
A single operator £= for cyclic addition, such that X £= Y would be equivalent to X = (X+1)%Y would be nice, perhaps with X €= Y equivalent to the reverse operation X = (X+Y-1)%Y. As for %, X and Y would usually be positive integers.
This comment is not intended to suggest the actual representations of the operators.
I think that it would be helpful to add to the NOTE something about curcumstances in whivh the delete operator actually "works".
"ECMAScript does not perform integer division". It can, of course, but not directly with an existing operator. I'd have inserted "directly".
The lack of a direct "div" (integer divide) operator is much regretted. Perhaps "\" could be used for it, with "\=".
English grammar requires that the section heading should have 'Does-not-equal' ; cf. section 11.9.5, which has 'Does-not-equal'.
The section may not include all possible compound assignments ??? perhaps the others are redundant. I have wanted to use at least one (I cannot recall what) apparently not provided, though, and saw no direct alternative.
It is a pity that the string representing the ECMAScript code statement which is the topic of this subsection is the same string as that frequently used for an action internal to the ECMAScript system, as for example in 12.10 step 6. It is much more difficult than it would otherwise be to scan the document to find further information relating to the 'throw' statement.
Possibly the word for the "internal" throw could be changed to 'raise'; 'raise' is used only once in the Standard, where a synonym could be used ('give' might do).
It would help if the final line of 12.13 were accompanied by an indication of where to look for an explanation of the effect of "Return (throw, GetValue(exprRef), empty)".
Not a standards matter; but it would be nice if Microsoft could get this one right. Try, in MS IE, parseFloat on an integer string of, say, 25 digits and on the same string with ".0" appended; and unary plus likewise. See Function parseFloat() ff.
When the .toString() method of a variable of type function is called, some browsers give the full source code as written, including layout and comments, whereas others give an expansion of a tokenised form, with a new layout, no comment, and some constant expressions evaluated.
On the whole, I much prefer the as-written form, which is extremely useful when writing about ECMAScript code.
I suggest that toString() here be allowed an argument. If the argument is absent or equivalent to false or zero, the browser should do what it did before. Otherwise, if it is odd, the browser should give the literal form if practicable, otherwise what it gave before; if it is even, the browser should give the tokenised form if practicable, otherwise what it gave before.
This and reduceRight being similar, this should have been called reduceLeft. Both names might be allowed.
No String.prototype.substr? I see that B.2.3 refers. I'd prefer substr to be retained in full; it is more useful than substring.
Number.MAXINT might be useful, with value 253. Granted, it's easily calculated, by those who know the value.
Not a standards matter; but it would be nice if Microsoft could get this one right. Try 0.007.toFixed(2). MS IE 8 and earlier give 0.00; other browsers correctly give 0.01. See toFixed.
Includes "Although the choice of algorithms is left to the implementation, it is recommended (but not specified by this standard) that implementations use the approximation algorithms for IEEE 754 arithmetic contained in fdlibm, the freely distributable mathematical library from Sun Microsystems (http://www.netlib.org/fdlibm).. The link is to a page set dated January 1995.
Even by the time of ECMA 262 3rd Edn, the recommendation ought to have acknowledged that most computers include hardware floating-point instructions corresponding to most or all of what is needed for Math and accurate for IEEE Doubles. An implementor should use those, after verifying their specified or actual accuracy.
This could also be described in Cartesian co-ordinates as the angle from the x-axis of the point (x, y).
A note that for a large range of X, X|0 = Math.floor(X) might be useful; X|0 should be faster. Likewise (?) ~~X.
For this section, see also in JavaScript Random. Existing implementations, while compatible with this section, are of varying and sometimes low quality. Improvement would not, by today's standards, require much code; and algorithms are readily available.
I think "pseudo-randomly" should have its hyphen.
It seemed likely though not inevitable that the pseudo-random IEEE Double will be generated by way of a pseudo-random 64-bit unsigned integer. Those can be converted to Double in at least two ways.
(A) Take 53 bits, and use as the mantissa of a Double with positive sign and appropriate exponent; then normalise. Easily implemented efficiently.
(B) Divide by 264 and round to the nearest Double.
Method (A) gives an equally-spaced comb of possible results; the interval is always 2-53; there are 253 possible values.
Method (B) gives a comb which gets finer and finer as the actual values reduce; the interval varies from 2-53 to 2-64; there are many more possible values.
Both are compatible with Standard 15.8.2.14.
I consider Method (A) to give better results (and that, within the life of this Standard, it is possible for the difference to be significant).
I have been told of a JavaScript system which appears to be type (B).
Suggestion : insert as shown in italics, or better : "Returns a number value with positive sign, greater than or equal to 0 but less than 1, chosen randomly or pseudo-randomly with approximately uniform and evenly-spaced distribution over that range, ...".
Some current browsers apparently use only 32-bit generators, or less. How about indicating that full 53-bit performance is appropriate? Recent machines can easily support it.
2009-06-10 : I now know that implementation of Math.random is commonly worse than I thought.
It appears that Math.random can be a security hole. See, via HTML Temporary user tracking in major browsers and Cross-domain information leakage and attacks, a 325kB PDF of the same title, by Amit Klein.
The paper gives considerable information on the internals of Math.random in major browsers.
Therefore, I suggest that the ECMA standard should call for improved Math.random. It should be able to return all and only values N × 2^-53, for integer N such that 0 <= N < 2^53 - 1, with approximately equal probability. The seed should not be generated only from the clock time at start-up; mixing in the readily-available (in PCs) CPU cycle count at start-up would increase security. It should be possible to write, and perhaps read, the full internal state of the generator - useful at least in testing. If the initial seed carries no useful information, reading or deducing it should not add insecurity.
Experience has shown that many coders do not know how best to obtain, using Math.random, a random integer in the range 0 to N-1. I suggest that it would be worth adding that to the language, perhaps as a method Math.randInt(N) or else just as Math.random(N). Code has been found needed in Usenet news:comp.lang.javascript FAQ for example.
Math.random traditionally takes no arguments. It could be enhanced by allowing an argument which could be an Object representing by its properties the internal state of the generator, updated at each call. A user could then, for example, set a specific state in order to get reproducible behaviour for testing. I now (2009-06-21) have substantially completed, in JavaScript Random, such a function.
Given a means of setting the initial state of a reasonably rapid generator from variables, it is desirable to be able to set the variables to random values; but that need not be so fast. If the language were to offer an optional routine to give slow but good random numbers in some machine-dependent manner, then implementors would be encouraged to provide one.
I have read that ECMAScript applications may need to generate GUIDs. That can be done, very badly, by using Math.random. There should be a new and conceptually distinct method which will return a well-formed GUID string. The core of the new method must be very much better than that of Math.random commonly is. Section 15.8.2.14 should include a statement of whether Math.random can be expected to give results good enough for cryptography or GUIDs.
Shuffling is commonly badly done. Therefore, SHUFFLE (and DEAL and DRAW) should be introduced as new methods of Array. Since they can be coded briefly and efficiently in Pascal and JavaScript (using Random(N)), there should be no difficulty in doing likewise in JavaScript engine source code.
JavaScript Random refers.
My general Date work is indexed at Date and Time Index and Links; my JavaScript Date work is via JavaScript Date and Time Introduction; see in particular JavaScript : Object DATE2.
Could there be a case for saying, early in 15.9.x, that both local date/time representations and GMT ones are handled? Also, since there is no provision for Leap Seconds, "UTC" is wrong; "GMT" had the right meaning, and "UT" may be formally correct. Personally, I use "GMT" when possible, as it has the right properties and is well-known.
Most date algorithms use either local or UTC routines, but do not need to use both. One can provide, using ECMA-262-3 code, new methods which call either the Local Civil Time (LCT) routines or the UTC routines, depending on a static variable of a DATE object. Accordingly, one piece of script can be written to do both the UTC and the LCT versions of a task. Tested and OK via DATE2. A native version should be easy to produce and more efficient than my implementation.
The "public" versions of the individual LCT and UTC methods might then be deprecated in Edition 6, and demoted to an appendix in Edition 7 or thereabouts.
This section of the standard defines time value. But there are
instances below it of references to that concept but using other words.
That is confusing. Also, one should be able to find all such references
by searching only for the obvious string. And date/time value or
DateTime value would be better - one could then readily
distinguish it from references to Date (YMD) or Time (hms) ?.
Paragraph 2 : Actually, "since 01 January, 1970 UTC" commences at the start of 02 January, 1970 UTC. Use instead "since 1970-01-01 00:00:00.000 GMT" or "since 1970 January 01 00:00:00.000 GMT" or "since 1970-01-01.0 GMT". Using "since 1969 GMT" would be accurate but confusing. Similarly elsewhere. Alternatively, "Time is measured in ECMAScript in milliseconds, +0 representing 1970-01-01 00:00:00.000 GMT.". Paragraph 4 is then redundant (better, put it at the beginning of paragraph 2, and adjust that : Time is measured in ECMAScript in milliseconds. The exact moment of midnight at the beginning of 01 January, 1970 UTC is represented by the value +0. In time values leap... .).
Paragraph 2 : Also the next larger integer, 2^53.
Paragraph 3 : Is it necessary to prohibit values between 8.64e15 and 253 milliseconds ?
Paragraphs 2 & 3 : I see no point in giving the range in years for 253 milliseconds in paragraph 2, when it is that for 108 days (about 273790 years) which matters.
Paragraphs 2, 3, 4 and elsewhere : ISO 8601 notation should be used wherever possible; 1970-01-01 00:00:00 then GMT or UTC or Z. Those who cannot understand it will not be wise enough to understand most of the document.
Needs to say that this is for UTC/GMT, not for LCT. That also applies to the next four sections.
Cannot those be largely replaced by a reference to ISO 8601:2004(E)?
Something should be said about years before AD 1 - that Astronomers' Notation is used, with years ... -2, -1, 0, 1, 2, ... and positive ones matching AD.
DayFromYear : I think it would be well to state verbally that 1970-01-01 is Day Zero. There is an expression which might be thought better, using I think z = y-1 and DayFromYear = 365*z + Math.floor(z/4) - Math.floor(z/100) + Math.floor(z/400) - 719162
Following material in 15.9.1.3 only applies where Summer Time is not used. Don't forget the Southern Hemisphere, where year-end is in Summer.
ASIDE: DaysInYear(y) = 365 + ( !(y%4) + !(y%100) + !(y%400) ) % 2
Noteworthy that ISO 8601 differs only in that Sunday is 7 instead of zero. OneToSeven = ZeroToSix | 7 ZeroToSix = OneToSeven % 7 ECMAScript should offer full support for the basics of ISO 8601. That means including ISO Day Number, Week Number, Year Number (best calculated and returned together in an Object) and Ordinal Date (Day of Year). Unfortunately, "ISO" has been used for what is really a subset "JSON" date format. Real routines intended to support ISO 8601 as such can have the full "ISO8601" un their names.
Uses the term "Time Zone" correctly (which is fairly unusual).
"The value LocalTZA does not vary with time but depends only on the geographic location." - false, since locations occasionally change their Winter Time. Consider :- The value LocalTZA depends on the geographic location and does not vary seasonally.
The Standard does not specify when the LocalTZA should be determined. With portable machines and travel, the true local winter offset from GMT can change at any time. If it is changed while a script or page is running, should LocalTZA be affected? Similar considerations apply to Summer Time rules in the next section.
The term "Summer Time" is preferred in a majority of countries.
A note of which countries currently cannot be accommodated by those rules would be inappropriate but amusing. Candidates are Iran, Israel, Morocco, Mauritius; Iran & Israel qualify, as they have (unless changed) non-Gregorian rules.
To always use the true current algorithm, it is clearly necessary to know the exact moment when the algorithm changes. The 2007 US DST change was defined to occur at the start of 2007-03-01, presumably implicitly in LCT. I think the UK has changed the definition formally from a moment when it first affects the clocks.
If a location changes Summer Time rules twice within 28 normal years, that mapping may not always be possible.
Note that for one hour each year, where Summer Time is used, one hour (or half-hour) of local time does not exist and one exists twice.
The section heading should have "Seconds".
There is an apparent alignment typo, on line 2 (compare with next lines) !
And 24 for HoursPerDay is not always right; it can also be 23, 23.5, 24.5, 25.
I think that it might be efficient to have a routine which returns, from a single calculation, an Object {h: , m: , s: , ms: } and likewise for YMD, YWD, YO.
See ISO 8601:2004; its PDF is (or was) free. This standard should not refer to an existing standard in a manner that suggests more compliance than there is. If the intention here is, as it appears to be, just to support JSON, then this standard should cite and use just "JSON", not "ISO". I suggest addinj "JSON" names and deprecating "ISO" ones, at the earliest opportunity. For code supporting ISO 8601:2004 more fully, see DATE2.
The Standard has "ECMAScript defines a string interchange format for date-times based upon a simplification of the ISO 8601 Extended Format. The format is as follows: YYYY-MM-DDTHH:mm:ss.sssZ". That is not a simplification; it is ONE of the compliant forms (althogh ISO 8601 says little of milliseconds, but clearly prefers the decimal separator to look like a comma, not like a full stop).
This functionality should be transferred to "15.12 The JSON Object".
In ISO 8601, T is used as a separator, not an introducer; there seems to be no example of it being used to untroduce a dateless time.
It should be possible to append a time offset indication to a pure date. Christmas Day in Hawaii is almost entirely after Christmas Day in New Zealand - without a fixed Offset, 2009-12-25 covers approximately 48 hours.
"Illegal values ..." : I deprecate this use of "illegal". There is surely no Civil or Criminal Law, in any jurisdiction, against it. "Illegal" here, and in many other places in computing, is an innapropriate word; and in each case an alternative can be used. Remember the tales of aged persons who have been quite shocked at seeing an error message "illegal operation blocked" or similar. Here, "incorrect" will suffice. (However, that paragraph has no value.)
In "NOTE 1" - In UTC, and usually in LCT. But, in some locations at the beginning or end of Summer Time, the LCT day may end at 23:00 or start at 01:00.
In "NOTE 2" - But GMT & UTC are adequately standardised. That should be said where general date string I/O is dealt with.
XML : I think that XML uses a very similar date/time format, but with more than three decimal places allowed. Therefore I strongly suggest that code for reading the format described above, and/or for reading true ISO 8601, should be required to accept any reasonable number of decimal places. Coding to allow that must be trivial.
A routine giving an undefined format is not of much use.
The (UTC) seems unhelpful; method toString does not give UTC.
Where arguments are ignored completely, it does not matter how many they are, or what they might represent.
Section ends "is set to the time value (UTC) identifying the current time.". But normally time is in the range 0 <= T < 24 hours. This is a case for "Date/Time value". And (UTC) is superfluous and confusing.
Perhaps the term "milliseconds from Epoch" could be introduced at the beginning of Section 15.9 and used wherever applicable thereafter; or "Epoch time" or "time from Epoch" - or define "t_ms" for the purpose.
It would be well to specify that YYYY/MM/DD will be recognised - at least five major browsers already comply. It may still be necessary that "77/04/22" be shifted to 1977; but "0077/04/22" should give AD 77. Also that "UTC" and "GMT" should be recognised.
Recognition of ISO8601-like input should be liberal; separator "T" or "t" or whitespace, accept Z or UTC or UT or GMT and offset with or without central colon. Even accept a.m./p.m., maybe.
Paragraph 1 :
• "UTC time value" is not defined as such; the "UTC" is
superfluous (or should be attached to other instances of "time value").
And "date" is wrong; I suggest "date/time" or"[current] instant]".
• "The parse function applies the ToString operator to its
argument and interprets the resulting string as a date;" - it seems to
me unreasonable to describe it as a date; a date is normally about 24
hours wide. Applies elsewhere. 15.9.3.3 uses "current time (UTC)".
The "return" should be the singular form, "returns".
There should be a method to get, from a Date Object, a string representing it in a format which is fully chosen by the programmer - toString(format) with a String argument - perhaps a global default string, or one a property of Date.
It could be useful to be able to get a string formatted for a given different Offset, including GMT; one might want to display, in Paris, the time in Beijing or Dallas.
Wnenever the specific functionality does not require otherwise, methods (e.g. setHours) should return a reference to the Object, thather than its valueOf(), for which I can see no general use (and that effect can be obtained with a simple unary +). Then, new Date().setUTCHours(22).getUTCHours() would work.
In each case, misuse of "time zone". It is the time offset which is intended to be taken into account. Change "in the current time zone" to "with the current time offset" throughout. Each contains "a convenient, human-readable form" - I suggest that it is not sufficiently clear whether there is expected to be an alphabetical part in the locale natural language.
If natural language support is to be provided, then it would be useful to require the system to provide arrays of names and abbreviations for months and days-of-week. The latter should have 8 entries, elements 0 and 7 both being for Sunday, which supports both ECMAScript/C numbers and ISO 8601 numbers.
The result when the Date Object holds NaN is not considered; I prefer to get a string "NaN" but some major browsers give "Invalid Date". It should be specified.
Misnamed, should be getTimeOffset. I suggest introducing the name getTimeOffset and strongly deprecating getTimezoneOffset.
Giving just UTC is a grievous and intolerable limitation, for ISO 8601. The LCT value will commonly be wanted. A matching routine named "toJSONString" or "toJSONDateTimeString" should be provided instead, and this one deprecated for future removal.
Enumeration of \s characters ?
Current browsers have differing interpretations of RegExp White Space. Numbers of characters accepted : MSIE8 : 6 ; Firefox : 22 ; Opera : 24 ; Safari : 25 ; Chrome : 25. In my RegExp Feature Testing, 'RegExp \S \s Testing' refers. Therefore I suggest that the Standard could well be more explicit in regard to the characters where present browsers differ.
The six \s characters common to all those browsers are \u0009 \u000a \u000b \u000c \u000d \u0020; and each of 26 characters is recognised in at least one browser.
Using "word" in conjunction with \w should continue to be avoided.
A strange title for a section dealing with properties that are more-or-less being removed. "Other Properties"? "Deprecated Properties"?
I'd prefer it to be retained in full. Method substr is useful; one often knows the desired length.
That was folly in the first and all subsequent instances; one only needs to calculate FullYear%100.
Likewise.
Paragraph referring to Section 15.9.4.2: Date.parse - change ISO to JSON or XML, since the specified capability is so limited in comparison with what ISO 8601 offers. Exchange "first" & "attempt".
Perhaps IEEE 754 Double arithmetic should become required throughout in the Date Object. In investigating date bugs, I have seen cases where 32-bit days or seconds from 1970 are evidently used.
See Usenet news:CLJ 24 Oct 2007 thread ECMAScript 4+ Date proposals (and DATE2).
In that thread, 25 Oct 2007 :-
"It would also be useful to have a routine which, given a duration in milliseconds, returns [an object holding] the duration expressed in days hours minutes and seconds.
Granted, an intelligent ten-year-old of my generation could do that; but few of the younger programmers seen to approach that standard reliably."
That would take no cognisance of Summer Time. The count should reverse after becoming zero, and the Object could also include a field value 0 for the zero second and +1, -1 on each side of it.
Since ECMAScript can determine (JavaScript Date and Time 2 : Demonstrations), given a correctly-set OS, the approximate longitude, and for places with Summer Time, also the clock change date/times and the hemisphere (N/S), it would be possible to provide a standard Method to return those in an Object.
It could also be useful (and trivial for a browser coder) to return the cloch change information directly obtained from the OS : that might be a TZ string. A Method for that would be allowed to give an OS-dependent return, with perhaps undefined when no useful form was available.
For calculating some holidays, support for Gregorian Easter Sunday would be useful. I have efficient compact code, traceably derived ultimately from the Calendar Act, in The Calculation of Easter Sunday after the Book of Common Prayer of the Church of England.. Other Easter code is in estralgs.txt etc.
Historically at least, document.lastModified has been of uncertain format, often losing information that was present in the RFC-specified Last-Modified header of the HTTP transfer. It should be easy and useful to provide as a static property Date.LastModified holding a read-only string exactly maching the variable part of the corresponding HTTP header line. The format of that header line is exactly specified by an RFC; as far as I know, in all browsers new Date() reads that format correctly, and this standard could explicitly make that a requirement.
Does it say that "GMT" and "UTC" should be recognised in date/time strings?
In Web page JavaScript : Object DATE2, I have developed a substitute for the native Date object. It should include all that has been suggested above, and more, except where another specific link is given.
The PDF of the Standard includes only a partial postal address - Switzerland does not by any means have the only Geneva.
Most publishers nowadays include, in all that they publish, the address of their Web Site ; and often an E-mail address.
The PDF includes nothing like an ISSN and no copyright notice and no library-indexing information such as is given in books. I feel that a PDF of a Standard should show the whole published paper document, and suspect that the paper version should have such things.
Thrown in swiftly en passant; should be reconsidered / repositioned.
Method Number.toString(Radix) should have an option (or alternative) such that 0xFFFFFFFF.toString(16, true) would give FFFFFFFF instead of -1, etc.
The standard .sort method is not necessarily stable. A stable alternative should be added.