On Wed, Jul 17, 2013 at 1:58 PM, Brendan Eich <brendan at mozilla.com> wrote:
> Anne van Kesteren wrote:
>> 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).

That makes sense. I think we moved towards Date because it exposes
more time-oriented API than number (doh). I didn't know number was the
preferred format for something without timezone.


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

Right, but we all use a number (and newer specs reflect that). Per
your explanation above that makes sense and I guess we should continue
to do that then. Not sure if startTime can still be changed.


--
http://annevankesteren.nl/

On Wed, Jul 17, 2013 at 1:58 PM, Brendan Eich <brendan at mozilla.com> wrote:
> Anne van Kesteren wrote:
>> 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).

That makes sense. I think we moved towards Date because it exposes
more time-oriented API than number (doh). I didn't know number was the
preferred format for something without timezone.


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

Right, but we all use a number (and newer specs reflect that). Per
your explanation above that makes sense and I guess we should continue
to do that then. Not sure if startTime can still be changed.