Frozen Date objects?

[Brendan Eich]

Anne van Kesteren wrote:
> On Wed, Jul 17, 2013 at 1:04 PM, Rick Waldron<waldron.rick at gmail.com>  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 
double).

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

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:
> http://www.w3.org/TR/DOM-Level-2-Events/ecma-script-binding.html Not
> sure why it was not implemented that way.

That spec says it is a Date object:

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

/be