Frozen Date objects?
Brendan Eich
brendan at mozilla.com
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 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
More information about the es-discuss
mailing list