Frozen Date objects?

Brendan Eich brendan at
Wed Jul 17 13:58:49 PDT 2013

Anne van Kesteren wrote:
> On Wed, Jul 17, 2013 at 1:04 PM, Rick Waldron<waldron.rick at>  wrote:
>> Can you explain why startDate was specified was a Date object?
> Because that's how JavaScript represents time?

No, *time* is stored as milliseconds after the epoch in a number (IEEE 

A Date object includes position on planet and timezone politics (see 

A Date object can be constructed from a timestamp number. A timestamp 
number is cheaper in fast VMs. So perhaps a timestamp number wins.

A timestamp number gives a universal time coordinate, as noted, though, 
so the question may come down to whether video elements should have 
timezone-specific start dates, for some reason I'm missing (interop or 
developer ergonomics or whatever; interop would seem to want UTC).

> Event.timeStamp was
> supposed to be a Date object too:
> Not
> sure why it was not implemented that way.

That spec says it is a Date object:

    This read-only property is a *Date* object.

> I don't really follow your line of reasoning. Existing APIs use a mix
> of callbacks and events. Should we not switch to promises where we
> can, but rather stick with precedent?
See above. Who says all precedents in specs are good hasn't been paying 
attention :-P. And in particular, a Date object is *not* merely a 
representation of *time*.


More information about the es-discuss mailing list