Date.prototype.getTime

[Peter Hall]

> It seems contradictory to have access to a finer-grained clock be
> more expensive.  Since its purpose is accuracy, you don't want to
> require allocation (and possibly a garbage-collection) to use it.  It
> is unlikely that you need the range of Date if you are concerned with
> precision.  Maybe the answer is to leave Date.prototype.getTime alone
> and create a new interface with less range and more precision:

Agreed. As Brendan commented, a static nanotime() makes a lot more sense.

Peter


On 6/28/06, P T Withington <ptw at pobox.com> wrote:
> On 2006-06-28, at 12:16 EDT, Peter Hall wrote:
>
> > // this flag can't go in the Date constructor because it is already
> > overloaded enough...
> > Date.useNanoseconds = true;
> > var dt = new Date();
> > nanoseconds = dt.getTime()*1000 + dt.getNanoseconds();
>
> On 2006-06-28, at 12:12 EDT, Brendan Eich wrote:
> > * A year from the epoch in nanoseconds requires more mantissa bits
> > than are in IEEE754 double. Return a pair [seconds, nanoseconds]
> > from a Date.nanotime() static method.
>
> It seems contradictory to have access to a finer-grained clock be
> more expensive.  Since its purpose is accuracy, you don't want to
> require allocation (and possibly a garbage-collection) to use it.  It
> is unlikely that you need the range of Date if you are concerned with
> precision.  Maybe the answer is to leave Date.prototype.getTime alone
> and create a new interface with less range and more precision:
>
> Date.tick:  getter returning an integer that increases linearly with
> elapsed time and is guaranteed to increase by at least 1 when
> accessed successively.  (I.e., can be used to measure the elapsed
> time of a trivial expression.)
>
> Date.tickScale:  float that is the ratio of Date.tick units to
> nanoseconds.
>
>
>
>