Date.prototype.getTime

[Bob Ippolito]

On Jun 27, 2006, at 8:07 PM, Peter Hall wrote:

>> I was under the impression that the following was more idiomatic,  
>> but I could be wrong:
>>
>> > var before = Date.now();
>> > doStuff();
>> > var after = Date.now();
>> > var elapsedTime = after - before;
>>
>
> Perhaps. But getTime() is what is implemented in es3, and I don't
> think this can change. The question is over the consistency of the
> precision of this value between implementations.
>
> I don't have a mac here to test, but I was under the impression that
> timing within Actionscript had a lower precision on macs than windows
> (as opposed to P.T.Withington's observation of the reverse).

I dunno what precision it has elsewhere, but it definitely has msec  
precision on OS X (Intel). You're definitely right in that Flash on  
Mac OS X is generally slow in comparison to anywhere else, but speed  
of execution and precision are very different things...

With the given snippet:
var l = 0;
var i = 4;
while (i > 0) {
	var n = (new Date()).getTime();
	if (n != l) {
		trace(n);
		l = n;
		i--;
	}
}

I just got the following traces (with plenty of other processes  
running):

1151465324221
1151465324222
1151465324223
1151465324224

> I don't think it is acceptable to standardise on anything coarser than
> 1 millisecond precision, and it is probably not practical (or indeed
> useful) to standardise on anything finer. getTime() should return an
> int, representing milliseconds, not a float. I don't know what you do
> about platforms where that precision is not possible to implement; and
> perhaps this is why es3 does not specify a precision. (It specifies
> only the fact that the unit is milliseconds, not the degree to which
> that measurement is accurate).

Why not a (64-bit) float? Millisecond precision is pretty weak, it'd  
be nicer to have higher precision where available and a float is the  
only reasonable way to get it (since nanoseconds don't fit well in a  
32-bit integer).

-bob