Anne van Kesteren wrote:
On Wed, Jul 17, 2013 at 1:04 PM, Rick Waldron<[email protected]> 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
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
