Date.prototype.getTime

[Brendan Eich]

On Jun 28, 2006, at 9:47 AM, P T Withington 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();

Forgot to comment on this bug: getTime() returns milliseconds since  
epoch, not microseconds.

> 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.

Precisely what I wrote several times in the wiki -- this lead to a  
"group assignment/return" proposal, which then was trumped by Lars's  
destructuring assignment proposal.  IIRC the discussion page for  
destructuring recounts some ways to optimize array return to avoid  
allocation, and we therefore agreed not to worry about the cost for  
the purposes of nanotime.  That does mean you either have to optimize  
if your clock is going to be perturbed, or else have a less accurate  
clock.

Just having a Date.nanotime() returning the current nanoseconds  
within the current second is problematic because users would have to  
call Date.now() separately and somehow cope with the latter falling  
in a different second.  So we think we want an atomic nanoseconds- 
since-epoch primitive.

>   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:

We absolutely must leave getTime alone, we are not breaking backward  
compatibility except in selected and few ways that actually improve  
the bugscape.

> 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.

That's not bad, but why not just give 'em nanoseconds since the epoch  
so they don't have to normalize.

/be