peterjoel at gmail.com
Wed Jun 28 09:16:16 PDT 2006
We're talking here about a significant upheaval of how time is
measured. I don't think this is necessarily a fair burden on existing
implementations, when compared to the value of the feature. Though it
is small, you are also potentially hurting performance, in situations
where many Date objects are created, because the nanoseconds would
have to be calculated, even if they are not needed.
I'd also be against returning a float from getTime(), since it
contradicts es3 and breaks compatibility. Programs expecting an int
could break if they get a float.
If nanosecond accuracy is desirable, perhaps we could circumvent the
performance issue with a "useNanoseconds" flag, and the compatibility
issue by adding a date.getNanoseconds(), analogous to the existing
getMilliseconds(). Implementations would be permitted to return 0, if
they choose not to implement it, or some lower resolution measurement,
if they cannot measure to that accuracy.
You could then get the total nanoseconds since 1970, like this:
// this flag can't go in the Date constructor because it is already
Date.useNanoseconds = true;
var dt = new Date();
nanoseconds = dt.getTime()*1000 + dt.getNanoseconds();
On 6/28/06, P T Withington <ptw at pobox.com> wrote:
> On 2006-06-27, at 23:32 EDT, Bob Ippolito wrote:
> > 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).
> My point exactly. Even in an interpreter, 1ms is a looong time these
> days. And floats are no longer expensive.
> Adding something like Date.now() would make optimization easier for
> implementers (might translate to only a few instructions on a decent
> architecture, e.g., scale the cycle-count register by the system
> clock frequency).
More information about the Es4-discuss