Frozen Date objects?

Anne van Kesteren annevk at
Wed Jul 17 15:05:45 PDT 2013

On Wed, Jul 17, 2013 at 1:58 PM, Brendan Eich <brendan at> 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:
>> 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.


More information about the es-discuss mailing list